AMOS
An AI agent orchestration control plane, running in production org-wide — routing, investigation, and permission enforcement built in from day one.
A control plane for AI agents, not a chatbot in a channel
AMOS is the answer to what happens once an AI agent has to do real work inside a real organization — not a single assistant that lives in one channel, but a control plane that routes requests to the right specialist, investigates before acting, and enforces permissions in code rather than in a prompt. It runs in production today, coordinating agent work org-wide inside a large regulated organization.
Coordination and governance, not model capability
The hard part of AI agents at real scale was never getting a model to answer well — it was everything around that: routing a request to the right specialist without a human triaging it first, making sure an agent never sees or touches more than the person asking is allowed to, and proving all of that holds up under real production load.
Deterministic where it can be, governed where it can't
Routing runs on explicit rules first, with a model as tiebreaker only when nothing matches — the expensive reasoning happens after the cheap decision, not before. Every action passes a permission gate enforced in code, not a prompt, and every read is checked live against the actual person asking. The result is a system that behaves the same way whether a human is watching or not.
- 01IngressChat today — issue tracker & code host planned
- 02Control planeRoutes work, correlates every surface to one session
- 03Dispatch → route → investigate → actRead-only investigation before any governed action
- 04Permission gateDeterministic, fail-closed checks — code, not a prompt
Every action passes the permission gate before it runs — the model never holds standing access it shouldn't.
Deterministic routing before any reasoning runs
Every request is matched against explicit rules first — regex, exact match, context checks — with a model used only as a tiebreaker when nothing matches, and a fallback for everything else. The expensive reasoning only happens after the cheap, deterministic step already picked the right playbook.
Read-only investigation, then governed action
Nothing gets touched on the first pass — a read-only investigation runs first, and only after that does a separate, permission-checked execution step call tools or write anything. The two are kept structurally distinct so a wrong guess during investigation can never turn into an unwanted action.
Deterministic permission gate, not a prompt instruction
Every tool call passes a chain of code-level checks before it's allowed to run — default-deny, fail-closed, with no exception for "the model seemed sure." The model never holds standing access to anything it shouldn't; the check happens in code, and it's covered by hundreds of automated tests.
Per-requester access, not a shared bot identity
Reads get checked live against the actual person asking, not a broad shared identity — so a session can never surface anything the human asking isn't already entitled to see. That per-requester model is applied consistently across every connected system, not bolted onto one integration.
One session, resolved across every surface
A lightweight correlation registry resolves a link, a ticket, or a thread back to the single session that owns it — so a conversation that starts in one place can be picked up from another without starting cold. Proven under a real shutdown test: a core service was pulled mid-production, and the conversation it was carrying finished with zero data lost.
Composable configuration, most-specific wins
Behavior is assembled from layered configuration — organization-wide defaults, team-group overrides, and individual-team specifics — merged at build time and rendered per request. Security-relevant configuration is the one deliberate exception: it can only be set at the top layer, so no more specific layer can ever weaken it.
Scheduled work, not just reactive replies
Work doesn't have to wait for someone to ask — jobs run on a schedule or on demand, in three shapes: plain deterministic code with no model involved at all, a full agent run through the same pipeline as a live request, or a lightweight gate that decides which of a fixed set of agent routes to trigger. Every job runs isolated, so one stuck job can never take the rest down.
Harness and model chosen per task, not fixed platform-wide
Neither the coding-agent harness nor the model is a platform-wide default — both are a configuration decision made per route. One task might run Claude Code against Sonnet over the Anthropic API, another OpenCode against an open-weight model hosted on AWS, a third Codex CLI entirely — each picked for fit and cost, never locked to one vendor's tooling.