Why Overcut Is Building the Run and Control Layers for AI Agents in the SDLC

Ask an engineering leader a simple question about the AI agents already working in their codebase and watch the room go quiet. What did the agent change last week? Under whose permissions? Was it reviewed before it merged? Could you reproduce the exact run if an auditor asked? Most teams can't answer. They care, but nothing in their stack was built to answer. They have agents that write code. They don't have anything that runs those agents reliably or controls what the agents are allowed to do.

That gap is the whole story of the last two years. The first wave of AI in software was about the individual developer. Copilots sat inside the IDE and made a single engineer dramatically faster at writing, refactoring, and explaining code. That worked, and it's still working. But it left a strange situation in its wake. The intelligence arrived before the infrastructure to operate it. We have agents smart enough to fix a bug, and no standard way to trigger that fix from the ticket that reported it, run it in an isolated environment, check it against policy, and leave a record that survives an audit.

Overcut is building the two layers that close that gap. A run layer that turns an agent from a chat session into a governed unit of execution, and a control layer that sits above the agents and decides what happens, when, and under what rules. We think these are the two layers that will still matter in five years, long after today's model leaderboard has been reshuffled a dozen times. Here's why.

The model is not the missing piece

There's a comfortable assumption in the industry that the path forward is a smarter model. Better reasoning, longer context, cheaper tokens, and eventually the agent just handles everything. We don't buy it, and the market is quietly proving the point.

Look at where the frontier labs and hyperscalers are actually investing. Bring-your-own-model is now standard. Enterprises route between Claude, Gemini, GPT, and open weights depending on price and task. The model has become a swappable component. When the smartest part of your system is the part you can replace with a config change, the durable value has to live somewhere else.

It lives in the two things that are genuinely hard to build and genuinely hard to rip out. The first is execution. Getting an agent to do real work against a real codebase means cloning the right repository, injecting the right tools with the right scopes, running in isolation so a bad step can't touch production, coordinating multiple agents when one isn't enough, handling retries, and capturing everything that happened. That's the run layer. The second is control. Deciding which events should trigger work at all, what requires a human to approve, which policies apply, and producing an audit trail that a regulator or a security team can actually trust. That's the control layer.

Neither of those gets solved by a better model. A smarter agent that runs in an ungoverned environment is a bigger liability. The more capable the agent, the more it matters that something above it is deciding what it's allowed to touch.

The run layer: making an agent a unit of execution

The industry borrowed a useful pair of words from network and cloud infrastructure. There's a data plane, where work actually happens, and a control plane, where the rules live. Every serious piece of enterprise infrastructure has both. Compute has both. Networking has both. AI, so far, mostly has the first one, and even that is held together with glue code.

Our run layer is the data plane for agentic work in the SDLC. The core design decision behind it is that an agent is not a conversation. It's a unit of execution with a defined responsibility, a set of tools, a permission scope, and a runtime it can't escape. When Overcut runs an agent, it spins up an isolated sandbox, clones the repository dynamically, and injects only the tools that agent's role is permitted to use. Multiple agents can run in parallel inside a single step, coordinated by an orchestrator that routes context between them, handles retries, and manages the lifecycle of the whole thing.

A few decisions in that layer are worth explaining, because the alternatives are tempting and we think they're wrong.

Tools are an abstraction over the underlying integrations. An agent doesn't call the GitHub API or the GitLab API. It calls create_pr, and the run layer maps that to whatever forge the workflow targets. Same for create_ticket, write_file, post_comment. This feels like a small thing until you realize it's what makes a workflow portable across a mixed enterprise stack. If the agent knew it was talking to GitHub specifically, every workflow would be welded to GitHub. By keeping the agent's vocabulary at the level of intent, the same review workflow runs whether the code lives in GitHub or GitLab and the tickets live in Jira or somewhere else.

Steps have memory, but it's scoped tightly. Each step in a workflow can accumulate persistent learning across runs, so an agent doesn't rediscover the same workaround for the same flaky test suite every single time. But that memory stays scoped to the step. A global brain that quietly steers every agent everywhere is exactly what we wanted to avoid. Persistent learning is powerful and it's also dangerous, because a confident wrong lesson propagates. Scoping memory to the step keeps the blast radius small and keeps the behavior legible when you go back to understand why an agent did what it did.

Flow behavior is decided at runtime. Workflows are sequential by default, each step passing context to the next, but the interesting decisions happen through agent reasoning inside a step, and parallelism happens through multi-agent sessions the orchestrator coordinates. Agents can delegate work, split a task, and aggregate the results. The workflow defines the boundaries and the agent exercises judgment inside them. We think that balance, structure on the outside and reasoning on the inside, holds up better than either a rigid state machine or a single agent improvising the entire process.

The control layer: governed autonomy is the only autonomy worth shipping

If the run layer answers "how does the agent do the work," the control layer answers "should it, and who says so." This is the layer we care about most, because it's the reason a real company can let autonomous agents touch its codebase at all.

Start with the trigger model, because it's the sharpest fork in the road. IDE copilots and coding assistants are developer-initiated. A person opens the tool, chooses an agent, pastes context, and reviews the output. That's fine for individual productivity, but it means the agent only works when a human remembers to summon it. The control layer inverts this. Work is system-initiated. A ticket gets labeled a bug, a security advisory lands, an SLA breaches, a pull request opens, and a workflow fires on its own. The organization's own signals become the triggers. Nobody has to remember to run anything.

That inversion is only safe because of what sits around it. Every workflow carries scoped permissions, so an agent operating on a documentation task literally cannot reach the tools a deployment task would use. Mandatory checks and human approval gates pause the workflow at exactly the points where judgment is required, and continue only once a person signs off. And every run captures evidence as it goes, the diffs, the tests, the logs, the reasoning, into an audit trail that's there whether or not anyone ever asks for it. We built the system biased toward producing that record by default, because the cost of not having it shows up precisely when you can least afford to reconstruct it.

There's a second decision in the control layer that shapes everything: control lives where work already happens. Developers do not manage Overcut's agents from a separate AI console. They manage them from Jira, GitHub or Slack, from tickets, comments, reviews, and approvals. A status transition or a label change is a control action. We made this choice because every new surface an engineering org has to learn is a tax, and because the SDLC already has a control surface that teams trust. The move is to make that surface programmable. Jira stays the system of record, the Git forge stays the execution surface, CI stays whatever it already is, and Overcut owns the workflow logic, the state machine, and the guardrails that connect them.

That last point is the one that separates a control layer from a feature. A single-vendor platform can add agents and even add governance, but its governance stops at the edge of its own ecosystem. GitHub's agents assume GitHub Issues and Actions. An Atlassian tool anchors its audit trail in Atlassian. The problem is that no real enterprise lives inside one vendor. They run Jira for planning, GitHub or GitLab for code, some separate CI system, an identity provider, and an approval process that predates all of it. Governance that only works inside one of those boxes governs a corner of the organization. The control layer has to be neutral, sitting above the tools and treating each one as an execution target, and that neutrality is exactly what lets Overcut give a company one workflow engine and one audit trail across a stack that no single vendor owns end to end.

Workflows are the product, agents are the actors

Here's the design choice that ties the two layers together, and it's the one we're most confident about: model the workflow first, and let agents be actors inside it. Most of the market does the opposite. They start with an agent and try to bolt process around it. We start with the process, an explicit object with triggers, conditions, steps, approvals, timeouts, and rollbacks, and drop agents in as the units that do the reasoning-heavy steps.

This matters because software development runs on workflows, triggered by events, governed by policy, and shaped by human judgment. A sequence of prompts cannot represent any of that. A bug is reported. Requirements change. A security advisory lands. A review is requested. A fix is applied. Documentation drifts out of sync. Today most teams hold that flow together by hand, with a person deciding what to run, on what context, in what order, and how to stitch the results back together. That person becomes the human orchestrator of a pile of disconnected tools, and it doesn't scale. Modeling the workflow explicitly is how you take that coordination out of a person's head and put it into a system that runs the same way every time, produces the same evidence every time, and can be inspected after the fact.

It also changes what the human does, in a good way. Instead of executing steps, people define the policy, decide what needs approval, and review outcomes rather than raw output. Their job becomes orchestrating intent. That's a higher-impact role, and it's the role engineering leaders actually want their best people playing.

Adoption you can start on Monday

A layer only matters if teams can actually get onto it, so the run and control layers ship with the SDLC already modeled. Every stage of the lifecycle, from intake and triage through planning, implementation, review, documentation, and maintenance, comes as a prebuilt, configurable, policy-driven playbook. Teams can run them as-is, customize them, or compose new workflows on top. Bug triage and root-cause analysis, autonomous code review, CI failure remediation, dependency and security patching, test generation, cross-repository standardization, and doc updates are concrete workflows with measurable outcomes.

That's the difference between a platform you build on and a product you adopt. The hyperscalers are racing to ship the building blocks, the agent runtimes, the identity primitives, the tool registries. Those are real and useful, and Overcut runs happily on top of them. But an enterprise that just wants governed bug triage across Jira and GitLab does not want to assemble that from primitives and then own the maintenance forever. It wants the workflow to exist on day one, with the guardrails already wired in. Building the run and control layers as a finished, cross-platform product is how you compress time-to-value from a year of platform engineering to an afternoon of configuration.

The market is converging on exactly this

The strongest signal that these are the right layers is that the whole industry is now pointing at them. Gartner's 2026 Hype Cycle for Agentic AI names agent orchestration, agentic AI governance, agent management platforms, and AI agents in software engineering as core innovations shaping the space. They're the through-line of where enterprise AI is heading, and they map almost one-to-one onto the run and control layers.

The adoption curve backs it up. Gartner's 2026 CIO survey found only 17% of organizations have deployed AI agents, while 42% expect to within the next twelve months and another 22% the year after, the most aggressive adoption curve of any emerging technology in the survey. Software engineering is already the standout category. The demand is arriving fast, and it's arriving into a gap where most teams have agents but no dependable way to run and govern them.

Gartner is also clear on the shape adoption should take: fully autonomous agents aren't ready for most enterprise use cases, and semiautonomous deployment with human supervision is what organizations must plan for. That's the exact operating model the control layer is built around. Human approval gates, scoped permissions, and evidence capture are how you run supervised autonomy at scale and then dial the supervision down as trust grows, on your schedule rather than the model's. The reliability of agentic work comes from the system around the agent, the isolation, the retries, the checks, the audit trail, far more than from any single model call, and that system is precisely what the run and control layers are.

Where this goes

Step back and the shape of the bet is simple. The model layer is consolidating into something you rent and swap. The developer-tool layer is crowded, improving fast, and mostly optimizes how one engineer works. The layer that's underbuilt, and that an organization needs before it can trust agents at scale, is the pair that runs the agents and controls them. That's where Overcut is planting, and building it cross-platform from the start is what makes it defensible.

The longer arc is a persistent, governed population of agents embedded across planning, implementation, review, and maintenance, a standing workforce the organization operates the way it operates any other critical system, through policy, approvals, observability, and a runtime it controls. You can't have that workforce without a run layer strong enough to execute real work safely and a control layer strong enough to keep it accountable. Every other capability, the workflows, the use cases, the memory, the analytics, sits on top of those two.

AI made individual developers faster. The run and control layers are how organizations turn that speed into something continuous, reliable, and governed. The market has already settled whether the SDLC needs these layers. The open question is who builds them to work across the whole toolchain instead of one vendor's corner of it. That's the thing we're building, and we think it's the right call.