# The Agentic Engineering Platform: You Have a Coding Agent. Now What? > Use a governed agent harness to superpower the full spectrum of engineering work. - Canonical: https://graymatter.ch/blog/agentic-engineering-delivery/ - Locale: en - Body language: en - Published: 2026-10-15 - Author: Nikola Novoselec - Tags: Agentic AI, Platform Engineering, Zero Trust --- *Part 1 of the Agentic Engineering Platform series.* So you have GitHub Copilot, Kiro, OpenCode (hopefully not with your AWS Bedrock API key stored locally on a workplace device with local administrator privileges), or whatever else your AI adoption programme decided is the future. It can create SDD plans, design, implement, test, and deploy. It can review a change and help correct what the review finds. Are you shipping code faster than ever, burning (b)millions of tokens, only to watch the efficiency gains evaporate before they reach delivery? If the adoption programme accelerates coding while the next dependency still requires the same manual work, the agent brings you to that bottleneck sooner. More generated change means more work waiting for the unchanged delivery path to absorb it. That is additional coordination, not the transformation the programme was supposed to deliver. The ambition is simple: **use a governed agent harness to superpower the full spectrum of engineering work.** That means being able to deliver a solution end to end across application code and infrastructure operations, as well as handle a code change or a standalone operational job. The engineer should be able to ask the agent to do the job, rather than take its instructions to another terminal and do it by hand. ## The Task Can Be Narrow. The Platform Cannot. Not every engineering task is an end-to-end solution delivery exercise. A developer may simply need to change code in an existing project whose delivery pipeline already works, letting the accepted change propagate through that pipeline. Agent-assisted coding is useful in that setting. The mistake is treating that setting as the whole enterprise. An operations engineer may simply need to update and patch infrastructure, reconfigure switches, or deploy new firewall rules. Those are engineering objectives in their own right. The platform should let the engineer perform that bounded work using the agent, under the applicable operational controls. Requiring every request to begin in an application repository would exclude the very responsibilities the platform is meant to support. A migration from VMware to AWS is another valid objective. It may involve substantial investigation and a carefully staged transition, without introducing a new application feature at all. Bounded does not mean small or harmless. It means the agreed systems, constraints, permitted changes, and expected result define the task. An agent does not get permission to redesign the surrounding estate because it sees an opportunity to improve it. The same breadth applies within software engineering. Bootstrapping a new project, modernizing a legacy codebase, and maintaining an established service require different starting points. [Spec-driven development](https://graymatter.ch/blog/spec-driven-development/) gives the work an agreed purpose and observable acceptance criteria. Existing capabilities should be reused where they already meet the requirement. Completion follows that purpose. For a coding task, it may mean the intended behavior is active through the existing pipeline. For a switch change, the required configuration and network behavior have to be established. A read-only diagnosis can end with supported findings and a proposed plan. It should not silently become a write operation, and an execution task should not quietly shrink into advice for somebody else to carry out. ![Three kinds of work share a governed agent harness: end-to-end delivery combines application code and infrastructure operations; an existing-project code change uses its current pipeline; standalone operations cover patching, migration, switches, and firewall rules. Each has its own result, scope, and permissions; the examples are not a required sequence](/images/blog/agentic-engineering/12-engineering-scope.png) *The platform supports the whole solution, an existing-project code change, or a focused operations job. The task sets the scope.* ## Follow the Work Beyond the Code Some objectives do cross those boundaries. Consider an application used in a sorting center of a large logistics company, with its backend running on Kubernetes in a cloud service provider. The application can be correctly implemented and deployed while the IAM integration or site-to-cloud configuration is still unfinished. The application team has completed its change; the sorting center still cannot use the solution. The remaining work can include IAM integration, DNS and certificates, reverse-proxy and API-gateway configuration. At the site, the local firewall and IDS/IPS need the appropriate configuration. Remote firewall policy must allow the intended communication. In the cloud, the VPC and gateways, cloud firewalls, network security groups, and load balancers have to agree with the design. Kubernetes and the service mesh have their own configuration to deliver. The network underneath is part of the same problem. Routers and switches, cloud interconnects, and the redundancy needed for the required failure tolerance do not become correct because an application pipeline passed. The investigation must establish what can be reused and what needs to change. The **software delivery lifecycle (SDLC)** includes DevOps, CI/CD, deployment, and operations. It is vastly more than coding. Accelerating the application work alone leaves the supporting configuration to set the pace. The platform must support the engineers responsible for those systems too. When work crosses teams, the agreed objective, proposed changes and evidence should travel with it. Each domain owner reviews and executes their part under their own permissions. ![A sorting-center solution needs application code, testing, and deployment together with IAM, DNS, certificates, traffic routing, site security, cloud networking, Kubernetes and service mesh, and the underlying network and redundancy; the grouped dependencies are not a literal packet-hop sequence or an estimate of effort](/images/blog/agentic-engineering/12-lifecycle-bottleneck.png) *End-to-end delivery crosses application and infrastructure responsibilities.* ## Make the Engineering Work Executable An enterprise may already have capable agents, SDD workflows, infrastructure pipelines, identity services, and an established change process. Those assets are part of the solution. The platform's job is to connect those capabilities to engineering work across the enterprise, not to purchase another specification or deployment workflow and announce the lifecycle solved. The agent needs to work with the systems and procedures engineers actually use. That can mean investigating infrastructure, applying an authorized patch, or submitting a code change through an established pipeline. The platform must connect useful reasoning to executable engineering work. A beautifully written runbook for the next person is still a handoff when the task was to perform the operation. That does not mean replacing working infrastructure pipelines with an agent holding administrator credentials. Code and infrastructure-as-code can use existing repository and delivery controls. The agent can author IaC under repository permissions while its target access stays read-only; the existing infrastructure pipeline applies the accepted change outside authoring execution. Other operational work needs an approved plan and separately authorized target writes. Plan approval alone grants none of those permissions. ![An agreed application and infrastructure objective uses repository review, CI, acceptance, and existing pipelines for code and IaC, or separately authorized direct operations through Zero Trust interfaces; both paths lead to verification of recorded outcomes and actual target state](/images/blog/agentic-engineering/12-integration-scope.png) *Existing pipelines and authorized operational sessions support different kinds of engineering work. Evidence of the result remains necessary in either case.* The useful question is whether the platform can perform the agreed task using the appropriate engineering path, with a result the engineer can verify. How review, correction, and acceptance make that trustworthy deserves its own treatment. ## Access for the Job An agent with local administrator privileges can change the tools and extensions intended to guide it. Putting a security rule in that same environment and asking the agent to respect it is a poor foundation for enterprise access. The rule may be sensible. It is still editable by the thing it is supposed to constrain. That local freedom can be useful for engineering work. It belongs in an isolated, disposable cloud workplace, separate from the engineer’s device and its network access. The agent can work on the problem without inheriting everything the engineer’s laptop can reach. Access and acceptance controls stay outside that workplace, where changing a local file cannot remove them. [Zero Trust](https://graymatter.ch/blog/agentic-coding-zero-trust-governance/) enforces access before the agent reads protected information, not just before it changes something. Directed work uses the engineer’s verified identity and the permissions approved for the job. Permission to investigate a failure does not include permission to repair it. A convincing explanation of why another system might be relevant does not authorize access to it. Within those boundaries, the harness should arrive prepared for enterprise work. Rules establish conventions, while skills carry the approved playbooks. Extensions run the corporate workflow and checks. The engineer should not have to teach the same change procedure whenever a conversation resets. Successfully saved work and decisions survive the workplace’s destruction; unsaved work does not. Making execution disposable should not mean throwing away the engineering knowledge needed to do the next job. ## The Same Capability, With More Autonomy An engineer can start by asking the agent to carry out an approved patch. The platform should also let an autonomous process take responsibility for that work, rather than require the engineer to direct every run. **[Graduated Autonomy](https://graymatter.ch/blog/the-great-decoupling/#4-graduated-autonomy)** provides the architectural principles for that progression, with independent checks on agent decisions and human approval where needed. More independent decisions do not grant wider access. Both should use the same governed harness and approved procedures. Rebuilding the engineering capability for each autonomous operator would miss the point of having a platform. Each operator needs its own identity and an owner responsible for the job, not the engineer's login or private history. Direct autonomous changes must be approved in advance and narrowly scoped. They must also be reversible. ![Graduated Autonomy can shift decision responsibility from engineer-directed work to autonomous work where policy permits, using independent checks and human approval when needed. Both reuse the governed harness in isolated, disposable execution, while each task keeps its own identity and scope. Identity checks, Zero Trust access, target permissions, inspection, acceptance, and independent records remain outside agent control](/images/blog/agentic-engineering/12-graduated-autonomy.png) *Graduated Autonomy can move more decisions to agents. It does not transfer an engineer's identity or grant wider target access.* ## The Bottom Line The ambition is not to make every task an enterprise transformation programme. It is to let engineers perform the full range of their responsibilities through the agentic platform, from a bounded infrastructure change or an existing-project code update to a solution that crosses application and infrastructure teams. Give each task the access it needs, enforced through Zero Trust. Let the agent do the work in an isolated, disposable workplace using the enterprise's approved tools and procedures. Require evidence that it achieved the agreed result. Those capabilities also provide the foundation for autonomous systems to take on engineering responsibilities over time through Graduated Autonomy. Coding alone is barely scratching the surface. Later articles will explore the workplace that makes this work executable while deterministic controls bound its effects. We'll follow a change through review, correction, and delivery to evidence that it worked, and examine how autonomous operators reuse those capabilities under their own authority and process ownership. --- ## References **Earlier Articles Behind This Argument** - The Enterprise Coding Agent: https://graymatter.ch/blog/agentic-coding-zero-trust-governance/ - The Code Is a Side Effect: https://graymatter.ch/blog/spec-driven-development/ - The Spec Grew Up: https://graymatter.ch/blog/spec-driven-development-part-2/ - Graduated Autonomy (The Great Decoupling): https://graymatter.ch/blog/the-great-decoupling/#4-graduated-autonomy