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.

Add Roster to your platformDeploy Roster

One primitive. Four surfaces. Every consumer.

resolve() is the shared platform capability. Every engineering surface — agents, pipelines, internal tools, workflow engines — calls the same function through whichever transport already fits its context.

roster · control plane
resolve()
MCP
For agents
Claude Code
Codex
Cursor
Custom agents
CLI
For CI/CD
GitHub Actions
GitLab CI
Jenkins
Scripts
REST
For internal tools
Dev portals
Release systems
Incident tools
Backstage
WEB
For owners
Project owners
Admins
Delegations
Memberships
One deployment · same evaluation logic across MCP, CLI, REST, and web.

Ownership is scattered across the engineering stack

Platform teams inherit organizational logic spread across half a dozen systems. Each is useful for something. None answers every runtime question about who should act.

Source of truth
What it answers
Where it falls short
CODEOWNERS
Path-based review assignment inside a single repository.
Silent on approvers, escalations, project ownership, and delegation.
Service catalog
Nominal owner of a service or component.
Doesn't reflect current coverage, active delegate, or per-project responsibility.
On-call rotation
Who to page for an incident right now.
Not the right lookup for approvals, reviews, or business escalations.
Slack aliases · groups
Broadcast to a nominal team.
No resolution semantics, no audit trail, no delegation logic.
YAML · spreadsheets
Static ownership snapshots.
Drift the moment the org changes; nobody updates them.

Roster gives the platform a reusable resolution service rather than another static ownership screen — one that answers who should act for this project, this responsibility, and this moment.

Example: production release approval

A deployment pipeline is ready to promote Atlas to production. Instead of hard-coding a reviewer list in YAML, it calls the Roster CLI:

ci · pipeline step
$ roster resolve \
    "Who should approve the Atlas production deployment?"
Roster evaluates the project, release-approval participant, associated directory group, current membership, and active delegation — then returns the acting person.
request reviewadd deployment checknotify approvercreate ticketescalate if unavailable
keep what works

Complement your existing ownership systems

Roster doesn't replace your software catalog, CODEOWNERS, Git provider, incident platform, identity provider, workflow engine, or internal developer portal. Those systems can stay sources — or destinations.

CatalogCODEOWNERSGit providerIncident platformIdPWorkflow engineBackstage
roster handles

Who should act for this specific project, responsibility, and moment — resolved consistently across every surface the platform exposes.

Designed for platform control

Roster runs where your engineering systems already run and stays under platform-team governance end-to-end.

01
One-container deployment

Platform, REST API, MCP endpoint, CLI-compatible tool surface, and worker from one Roster deployment.

02
Environment flexibility

On-premises, private cloud, public cloud, or Kubernetes — deploy alongside the systems that need it.

03
Scoped machine identities

Represent CI jobs, integrations, autonomous agents, and scheduled workloads through dedicated service accounts or AI-agent identities.

04
Bring your own model

Keep the model provider, credentials, usage, and model selection under your control.

05
Local licensing

Plan enforcement is local to the deployment rather than requiring usage-based phone-home metering.

06
Delegated project control

Project owners manage their own projects, participants, memberships, and delegations within authorized boundaries.

07
Health & telemetry export

A built-in health dashboard surfaces readiness, workers, connectors, and replication. Enterprise deployments can export OTLP traces, metrics, and logs to your existing observability stack — never to Advantys.

What platform teams can standardize

Every one of these resolution questions gets the same answer, whichever surface asks — and the same audit trail.

01Approval lookup
02Service and component ownership
03Deployment sign-off
04Security review
05Architecture review
06Incident escalation
07Customer escalation
08Temporary coverage
09Project-specific responsibility
10Cross-functional ownership

Frequently asked questions

No. Roster resolves workflow responsibility at runtime. It can complement a catalog that records software metadata and nominal ownership.

Make organizational resolution a platform capability.

Give every engineering surface the same answer to “who owns this?” without centralizing every update in a platform backlog.

Add Roster to your platformDeploy RosterExplore all solutions