Standardize the “who” primitive across your engineering platform.
Give agents, CI pipelines, internal tools, and workflow systems one consistent way to resolve who owns, approves, reviews, or handles work.
Roster replaces fragmented ownership logic with a shared participant-resolution layer available through MCP, REST, CLI, and web.
Ownership is scattered across the engineering stack
Platform teams often inherit organizational logic spread across CODEOWNERS, service catalogs, YAML files, repository settings, GitHub teams, Slack aliases, on-call systems, approval workflows, internal portals, and spreadsheets.
Each source may be useful, but no single one reliably answers every runtime question about who should approve a release, own a service in this project, review a security-sensitive change, cover as the active delegate, or receive an escalation.
Roster gives the platform a reusable resolution service rather than another static ownership screen.
One service across every platform surface
Give Claude Code, Codex, and other engineering agents access to current organizational responsibility.
Use roster resolve from pipelines, scripts, and terminal workflows.
Add participant resolution to developer portals, release systems, incident tooling, and internal applications.
Let authorized administrators and project owners maintain projects, participants, memberships, labels, and delegations.
Example: production release approval
A deployment pipeline is ready to promote Atlas to production. It calls the Roster CLI:
Roster evaluates the project, release-approval participant, associated directory group, current membership, and active delegation. The pipeline can then request a review, add a deployment check, notify an approver, create a ticket, stop until authorization is received, or escalate when no participant is available.
The ownership logic remains outside the pipeline definition.
Complement your existing ownership systems
Roster does not need to replace your software catalog, CODEOWNERS, Git provider, incident platform, identity provider, workflow engine, or internal developer portal. Those systems can remain sources or destinations.
Roster handles the runtime organizational question between them: who should act for this specific project, responsibility, and moment?
Designed for platform control
Run the platform, REST API, MCP endpoint, CLI-compatible tool surface, and worker from one Roster deployment.
Deploy where your engineering systems already run: on-premises, private cloud, public cloud, or Kubernetes.
Represent CI jobs, integrations, autonomous agents, and scheduled workloads through dedicated service accounts or AI-agent identities.
Keep the model provider, credentials, usage, and model selection under your control.
Plan enforcement is local to the deployment rather than requiring usage-based phone-home metering.
What platform teams can standardize
- Approval lookup
- Service and component ownership
- Deployment sign-off
- Security review
- Architecture review
- Incident escalation
- Customer escalation
- Temporary coverage
- Project-specific responsibility
- Cross-functional ownership