Case study | Engineering operating model | Agentic AI and governance | Design programme, 2026
Key findings
- Agentic coding raises throughput, but throughput without governance moves risk faster than value. The design question is where humans stay in the loop, not whether to use agents.
- A three-plane model separates concerns cleanly: a control plane that decides, an execution plane that builds, and a knowledge plane that remembers.
- The first-draft toolchain covered the exciting parts of the lifecycle and skipped the dull parts that decide production readiness: infrastructure as code, observability, security scanning, secrets, incident management and feature flags.
- In a regulated domain, the target is semi-autonomous delivery. Full autonomy is explicitly off the table.
Status note: this is a reference design and operating-model study from a 2026 programme. It describes an architecture and the reasoning behind it, not a production deployment, and no productivity figures are claimed.
A product where mistakes carry legal weight
The programme concerned a legal-technology platform intended to help people who cannot afford representation prepare, check and submit court filings. The product promise sounds simple. The environment around it is not. Output that reads as legal advice can cross into the unauthorised practice of law in some jurisdictions. Filings must meet jurisdiction-specific rules. Personal and case data is sensitive. Accessibility is a legal requirement, not a nicety, for a public-facing service used by people with limited resources and, in many cases, limited English.
A company building this faces a familiar early-stage squeeze. The roadmap is wide. The engineering team is small. AI-assisted development promises to close the gap, and the tooling market for agentic coding changes monthly. Leadership needed a way to use that tooling without betting the company on a pipeline nobody could audit.
The design brief was therefore two-sided. Move faster by letting agents do real engineering work. And keep every decision that carries legal, security or financial weight under human control, with evidence.
Starting with an honest inventory
The first draft of the toolchain came from a survey of what was available: specification templates, a kanban board for agent tasks, persistent coding-agent runtimes, repository governance on GitHub, a code knowledge graph, a retrieval layer for documentation and an AI review tool. The list covered a lot of ground and looked complete.
The most useful exercise in the programme was a structured gap review of that list against the full software lifecycle. For each stage, from requirements through monitoring and knowledge management, the review asked: what does this stage need, which tool covers it, and what is missing? Mapping the stack to the lifecycle exposed that the draft was strong in the middle and thin at both ends.
The gaps were not exotic. They were the unglamorous controls that separate a demo from a service: infrastructure as code for repeatable environments, an observability stack for production debugging, security scanning against dependency and supply-chain attacks, an artifact repository for build outputs, secrets management, incident management, feature flags for safe rollout, API lifecycle governance, and architecture decision records to preserve the reasoning behind choices. Each one was added to the design, with an owner and a place in the pipeline.
A parallel register tracked product-level gaps with a priority for each: accessibility to WCAG 2.2 AA, AI reliability and hallucination mitigation, scalability and performance targets, vendor and third-party risk, a phased go-live plan, disaster recovery, ethical AI and bias audits, and user onboarding. Four of these were rated high from the start because they affect legal defensibility directly.
The three-plane model
The architecture (Figure 5) organises the factory into three planes with human gates above them.
The control plane holds intent and policy. It contains specification templates and versioned specs, task orchestration through a kanban board, coding standards and pull request governance, and tracking for risk, compliance and technical debt. Specifications are the source of truth. If a requirement is not in a spec, an agent does not build it.
The execution plane does the work. Coding agents run a plan, act and observe loop. Continuous integration builds, tests and runs static analysis. AI-assisted review comments on pull requests before a human reads them. Infrastructure as code provisions environments, and deployment automation releases software. Observability closes the plane so that behaviour in production is visible.
The knowledge plane remembers. A codebase knowledge graph maps relationships across repositories. Semantic retrieval gives agents and developers the right documentation at the right moment. Persistent memory carries decisions and context between sessions, and architecture decision records preserve the reasoning for later teams. Without this plane, every agent session starts cold and every new engineer rediscovers the same constraints.
Cross-cutting concerns sit beside the planes: trace replay and observability, secrets management and security scanning, evaluation and drift checks, and cost metering.
Where humans stay in charge
The decisive element is the row above the planes. Four gates require a named human approver, and the agents propose while the owners decide.
The specification gate approves what is to be built. Agents can draft and critique specs, and they can find contradictions and gaps, but a person accepts the scope.
The architecture and security gate covers changes to boundaries, data flows, authentication and trust zones. For a legal platform handling personal identity and case data, this is where zoning of public, application, personal-data and external-court areas gets reviewed.
The pull request gate controls merges. Automated tests, static analysis and AI review inform the human reviewer and do not replace one.
The release gate holds authority over deployment and rollback, supported by staged rollouts and feature flags so that a bad change can be contained quickly.
Figure 6 shows the delivery loop with the gates marked. Autonomy applies between gates. Nothing crosses one without an approver, and what the system learns on the way returns to the specifications and memory before the next cycle.
The same logic appears in the programme’s operating agreements. A responsibility matrix separated product and platform direction from legal and market direction and from corporate governance, and a decision matrix named a driver and an approver for each class of decision. A “joint decision zone” was recommended for changes that cut across functions, such as a pivot in the core product model or a stack overhaul, so that no single party could change them unilaterally. Governance of the machines and governance of the people followed the same principle.
Controls specific to the domain
Regulated products need controls that a general software factory will not include by default.
Output scanning screens generated content for anything that reads as legal advice before it reaches a user, with escalation triggers and a secure hand-off to licensed attorneys. A jurisdiction lock blocks cross-jurisdiction output. Consent is captured with timestamps. An immutable activity ledger records every action so that an audit can be reproduced.
Identity and access follow standard practice: multi-factor authentication, role-based access and separate workspaces for public users and legal professionals. Encryption covers data at rest and in transit. Personal identifiers sit in a dedicated encrypted store, and analytics strip personal data before use.
On the AI side, the OWASP Top 10 for LLM applications provides a shared vocabulary for threats such as prompt injection and insecure output handling, and the NIST AI Risk Management Framework gives a structure for mapping, measuring and managing AI risk across the lifecycle. The programme also adopted a quality governance approach built on the ISO/IEC 25010 product quality model, so that reliability, security, maintainability and accessibility are specified and tested as qualities, not hoped for.
What the design produced
The programme produced an operating model that leadership could reason about. It named the planes, the tools in each, the gaps that remained, the gates and the owners. It converted a long and fast-moving tool list into a lifecycle-complete architecture with explicit control points.
It also produced a position on autonomy that is easy to explain to investors, partners and regulators: the system is semi-autonomous by design. Agents handle drafting, implementation, testing and documentation at speed. People hold the decisions with legal, security and financial consequence. That position protects the product’s credibility, which is its scarcest asset, and it protects the team from the specific failure of agentic pipelines, where a plausible but wrong change moves quickly through an unattended process.
Measures to track once the factory runs are straightforward and should be set before launch: lead time from approved spec to production, change failure rate, escalation rate at each gate, defect escape rate, time to detect and recover from incidents, and the hallucination rate on user-facing output. These are targets for the programme to measure, not results it has reported.
Lessons for leaders
Audit the toolchain against the lifecycle. A tool list that feels complete usually clusters around the interesting stages. Walk every stage from requirements to monitoring and ask what is missing.
Specifications are the control surface. Agents are only as safe as the specs that bound them. Invest in spec quality, versioning and contradiction checks before investing in more agents.
Separate deciding, doing and remembering. Three planes keep governance, execution and institutional memory from collapsing into one tangled pipeline.
Put humans at gates, not in the middle of every task. Gates at specification, architecture, merge and release keep review effort where it has the most leverage.
Give regulated domains their own controls. Output scanning, jurisdiction locks, consent logs and audit ledgers are product requirements, and the factory has to enforce them.
Plan to replace tools. The agentic tooling market moves quickly. Keep specifications, evaluation suites, decision records and memory portable.
Recommendations
Teams starting a similar programme can move in this order. Write the lifecycle map and mark every stage with its current coverage. Stand up the control plane first, with specification templates and a task board. Add the execution plane with continuous integration, tests and infrastructure as code before adding more agents. Build the knowledge plane so that context persists. Define the four gates and their approvers in writing. Then add domain controls and measure the delivery metrics from the first sprint.
The author advises founders and product leaders on agentic engineering operating models. A working session can be booked through Topmate: https://topmate.io/raja_jeevan_kumar_maduri
Sources and method
This case study draws on the author’s programme design notes. Company and individual details are withheld. Public references: NIST AI Risk Management Framework (https://www.nist.gov/itl/ai-risk-management-framework); OWASP Top 10 for LLM Applications (https://genai.owasp.org/llm-top-10/); ISO/IEC 25010:2023 product quality model (https://www.iso.org/standard/78176.html). Figures 5 and 6 are the author’s reference diagrams.