AMOS.

An AI agent orchestration control plane in production across a large regulated organisation: deterministic routing, read-only investigation before any action, and permissions enforced in code.

Category
Software · AI infrastructure
Year
Ongoing
Role
Architecture, build & operation
Stack
Go · Kubernetes · Postgres · harness-agnostic AI layer
ArchitectureChatThreads and mentionsCode hostPull requests and reviewsIssue trackerTickets and commentsControl planeRoutes every request and correlates each surface to one sessionDispatchOwning teamRouteRules first, model lastInvestigateRead-onlyPermission gateIn code, fail-closedActPer requesterSession registryOne session across every surfaceCredential brokerShort-lived, scoped credentialsTelemetryEvery call: cost, latency, outcome

Overview

A control plane for AI agents, not an assistant in a channel

AMOS is what an AI agent needs once it does real work inside a real organisation. Rather than a single assistant in one channel, it is a control plane that routes each request to the right specialist, investigates before it acts, and enforces permissions in code rather than in a prompt. It runs in production today, coordinating more than 300 purpose-built routes across a large regulated organisation.

The challenge

Coordination and governance, not model capability

At production scale the hard problems sit around the model, not inside it: routing a request to the right specialist without a person triaging it first, guaranteeing an agent never sees or touches more than the requester is entitled to, and proving both hold under live load and through a deliberate service shutdown.

The approach

Deterministic where it can be, governed where it cannot

Routing runs on explicit rules first, with a model as tiebreaker only when no rule matches, so the expensive reasoning follows the cheap decision. Every action passes a permission gate enforced in code, and every read is checked live against the person asking. The system behaves identically whether or not anyone is watching, and every decision is logged.

Architecture

From a request to a governed action.

  1. 01
    Ingress
    Chat, code host and issue tracker, one session each
  2. 02
    Control plane
    Routes work and correlates every surface to one session
  3. 03
    Dispatch → route → investigate → act
    Read-only investigation before any governed action
  4. 04
    Permission gate
    Deterministic, fail-closed checks in code, not in a prompt

Every action passes the permission gate before it runs. The model never holds standing access to anything.

What it does.

  • Deterministic routing before any reasoning runs

    Every request is matched against explicit rules first: regular expressions, exact matches and context checks. A model is consulted only as a tiebreaker when no rule matches, with a defined fallback for everything else. The expensive reasoning runs after the cheap, deterministic step has already selected the playbook.

  • Read-only investigation, then governed action

    Nothing is modified on the first pass. A read-only investigation runs first, and only then does a separate, permission-checked execution step call tools or write anything. The two phases are structurally distinct, so a wrong conclusion during investigation cannot become an unwanted action.

  • Permission gate in code, not in a prompt

    Every tool call passes a chain of code-level checks before it runs: default-deny, fail-closed, with no exception for a confident model. The model never holds standing access. The enforcement layer is covered by close to 1,000 automated tests.

  • Per-requester access, not a shared bot identity

    Reads are checked live against the person asking, not against a broad shared identity, so a session can never surface anything the requester is not already entitled to see. The same per-requester model applies across every connected system rather than being bolted onto one integration.

  • One session, resolved across every surface

    A correlation registry resolves a link, a ticket or a thread back to the single session that owns it, so a conversation started in one place continues from another without losing context. Proven in a live shutdown test: a core service was stopped mid-production and the conversation it carried completed with zero data lost.

  • Layered configuration, most specific wins

    Behaviour is assembled from organisation-wide defaults, team-group overrides and individual team settings, merged at build time and rendered per request. Security-relevant configuration is the deliberate exception: it is set at the top layer only, so no more specific layer can weaken it.

  • Scheduled work, not only reactive replies

    Jobs run on a schedule or on demand in three forms: plain deterministic code with no model involved, a full agent run through the same pipeline as a live request, or a lightweight gate that selects one of a fixed set of agent routes. Every job runs isolated, so one stalled job cannot affect the rest.

  • 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 configured per route: one task may run Claude Code against Sonnet over the Anthropic API, another OpenCode against an open-weight model hosted on AWS, a third Codex CLI. Each is selected for fit and cost, with no lock-in to one vendor.

Want the next one to be yours?

Describe the system, who uses it and what it has to survive. You get a written view on scope, architecture and the first increment worth shipping.

Start a conversation