AI coding is quietly going multi-agent. It's no longer one assistant in your editor — it's a planner that hands work to a coder, a coder that hands off to a test writer, a security agent that gets pulled in for the risky change. The orchestration frameworks make this easy to set up. Almost none of them make it safe.
Here's the problem. The moment work crosses an agent boundary, the guardrails you carefully put on the first agent evaporate. The coder was scoped to src/auth/; the tester it delegates to inherits nothing. A low-trust agent hands a task to a higher-trust one and, in effect, launders its own permissions. Every hop is a place where scope widens, trust escalates, and — when something goes wrong — nobody can say which agent touched what.
For a hobby project, fine. For a medical device API subject to HIPAA and IEC 62304, that's a finding.
Sentrik routes and gates — it doesn't run your agents
Sentrik's new multi-agent routing is deliberately not another orchestration runtime. It doesn't spawn agents or execute their work. It sits one layer up and does three governance jobs: it decides which agent should handle a piece of work, enforces whether a handoff between agents is allowed, and records every move. Your harness — Claude Code, Cursor, a CI script, an SDK loop — still invokes the agent. Sentrik is the dispatcher and the gate, not the engine.
That boundary is the whole point. Routing is a small, auditable surface — match, authorize, record — sitting on top of the identity, trust, and task-scope primitives sentrik already enforces for a single agent.
You write the routes as rules
Routing rules live in .sentrik/routes.yaml, checked into the repo like everything else. First match wins; anything unmatched escalates to a human — fail-closed by default. Here's a slice from a real medical vitals API, with ePHI endpoints, security middleware, and device firmware:
# ePHI paths (HIPAA + 21 CFR 11) — only a high-trust agent; else a human
- id: phi-data
when: { task_type: [fix, feature],
paths: ["src/api/routes/patients.py", ".../vitals.py", ".../export.py"],
min_trust: fix:any }
to: phi-guardian-agent
on_unavailable: escalate
# Device firmware (C, IEC 62304 safety-critical) — human sign-off
- id: firmware
when: { paths: ["firmware/**"] }
to: firmware-agent
on_unavailable: escalate
# After any src/ fix, chain to regression tests (IEC 62304 §5.5)
- id: needs-tests
when: { after: api-general, touched: ["src/**"] }
to: test-writer-agent
- default: { to: human } # fail-closed catch-all You can dry-run a decision before anything moves:
sentrik route "fix export validation" --type fix --path src/api/routes/export.py
-> phi-guardian-agent (rule phi-data, action route) Because export.py handles patient data, the work doesn't go to the general-purpose coder — it's routed to the agent trusted with ePHI. Point the same command at README.md and it routes to a human, because nothing matched and the default fails closed.
What the gate actually enforces
The value isn't the routing table — it's what sentrik guarantees when an agent actually calls handoff:
- Scope is narrow-only. The receiving agent's authorized paths can only be a subset of the sender's. An agent that was scoped to the export endpoint can't hand off a task that reaches into
src/secrets/. Try to widen the scope, and the handoff escalates instead. - Trust is capped, never escalated. The receiver's effective trust becomes
min(sender, receiver), and it joins the delegation chain. A handoff can only ever narrow what an agent is allowed to do — never grant it more. That closes the privilege-laundering hole directly. - Escalation is a real human gate. When a handoff can't proceed — insufficient trust, an out-of-scope reach, too many hops — sentrik opens a pending approval and blocks the downstream action until a person resolves it. It never silently continues.
- Every hop is on the ledger. Each route, handoff, and escalation is audit-logged, attributed to a named agent, and carries the work item through the whole chain. When an auditor asks "which agent changed the export logic, and who approved it?", there's an answer.
A concrete flow
Say a developer asks the general API agent to fix input validation on the vitals CSV export. Here's what routing does:
- The agent calls
route_task. Becauseexport.pyis an ePHI path, sentrik routes it to thephi-guardian-agent, which is trusted for regulated data. - The API agent hands off. Sentrik checks trust, scopes the new session to the export path only, creates it as a child in the trust chain, and writes the hop to the ledger.
- The PHI agent fixes the bug and hands off again — this time to the test writer, per the "after any
src/fix, write tests" rule (IEC 62304 expects verification for changes). The test session is narrowed further and trust-capped again. - Then the PHI agent reaches for
src/api/middleware/encryption.py— outside its lane and above its trust. Sentrik doesn't let it through. It escalates, opens a human approval, and the work waits for sign-off.
No agent gained a permission it didn't start with. Nothing touched a file it wasn't scoped to. And the whole sequence — decision, two handoffs, one escalation — is on a signed ledger a compliance reviewer can read.
Why this belongs in a governance tool, not an orchestrator
A generic multi-agent framework will happily let your agents pass work around. What it won't do is tell you a handoff would have widened scope, cap the trust that flows across the boundary, force a human gate on a regulated path, or hand an auditor a complete chain of custody. Those are governance questions, and they only get harder as the number of agents grows.
Routing is available now — drive it from the CLI (sentrik route, routes, handoffs), from agents via MCP tools (route_task, handoff, escalate), or watch it live on the dashboard's Routes page.
pip install sentrik
sentrik route "your task" --type fix --path src/… Multi-agent coding is coming whether or not your compliance story is ready for it. The handoff is the new attack surface — govern it there.