AI Coding Agent Governance: Work Sessions and Gates
Make every AI coding agent declare its work first. Advisory leases on C4 elements, a preflight gate that answers allow, warn or deny, and an Architecture…
Make Every AI Coding Agent Declare Its Work First
Archyl is not another coding agent. It sits above the ones you already run -- Claude Code, Cursor, Copilot, Codex -- and gates every session against your documented architecture before the first line of code.
AI Coding Agent Governance | Work Sessions & Preflight Gate | Archyl
Govern AI coding agents with work sessions: advisory leases on C4 elements, a preflight gate that answers allow, warn or deny, and an Architecture Change Request when the architecture moves.
AI coding agent governance, multi-agent architecture, agent work sessions, AI agent conflicts, architecture guardrails for agents, MCP agent governance
Parallel agents collide silently
Three agents open three pull requests. Each is right on its own. Together they make the system three different things, and the first moment anyone notices is review.
Nobody knows what an agent is doing
An agent reads the repository, writes code and opens a pull request. Until that moment its intent is invisible to the rest of the team.
Hard-won context dies with the session
The pitfall one agent lost an afternoon to is gone when the session ends. The next agent walks into the same trap.
The agent declares the work
start_work_session resolves the task against your C4 model, takes advisory leases on the elements in scope and opens with a briefing: relevant ADRs, guardrails and pitfalls from earlier sessions.
The preflight gate answers
allow, warn with named reasons -- another session already holds an element -- or deny on an exclusive conflict such as a schema migration. One verdict, before any code is written.
Guardrails hold while it codes
On Claude Code, the Guard hook blocks an edit that violates a conformance rule before it is written. Other agents run the same check over MCP.
The session gives context back
finish_work_session records the outcome, pins decisions and pitfalls onto the elements touched, and opens an Architecture Change Request when the architecture moved.
Every session declares the C4 elements it is about to change. The next agent sees who is already in there, in its briefing, in the console and on the diagram.
allow, warn or deny, decided from live leases and your conformance rules. Pass exclusive to stop a session outright when work must not race with anybody.
Memory that survives the session
Notes, conventions and pitfalls attach to architecture elements. The next session gets them back automatically, ranked by freshness.
Every session in the organization, live: who is working on what, holding which elements, behind which gate, and how fresh the last heartbeat is.
Architecture Change Requests
An agent that restructures a service files a proposal instead of quietly editing the model. Agents propose, humans merge.
Any agent that speaks MCP
The work-session tools are plain MCP. A curated 16-tool coding profile keeps agent context focused instead of flooding it with the full catalog.
Several agents on one codebase
Two agents editing the same container in the same hour find out at session start, not at review. The warn names the other session.
Work that must not race
Schema migrations, contract changes and renames that touch every caller open with exclusive. A conflicting session is denied instead of warned.
Onboarding an agent to a codebase
A new agent starts with the architecture slice that matters, the decisions that constrain it and what the last session learned the hard way.
Governed sessions, five minutes from now
One command installs the Harness alongside the agents you already run. Available on every plan.