Agentic engineering governance: build riverbanks, not gates

If you work in platform or engineering leadership right now, you're probably being asked to make agentic engineering work across your company. Not a pilot in one team. The whole thing. Model access for everyone, guardrails so agents can't be used to cross security boundaries, a marketplace of plugins someone has actually vetted, MCP servers for the productivity and communication tools people use every day, somewhere safe to run the apps non-engineers are vibe-coding on their lunch break. And, underneath all of it, a genuine rethink of how software gets built when an agent writes most of the code.

In most companies, that lands on a handful of engineers.

I think that's the most interesting problem in enterprise technology at the moment, and I'm lucky enough to be working on it. The tooling is extraordinary. The productivity gains are real. The people who work out how to govern this well, without strangling it, are going to define how engineering works for the next decade. But the problems are new, and a lot of teams are discovering them one at a time, the hard way. Here are the ones I keep running into, and what I think you do about them.

1. How do you deliver rapid AI gains without compromising security?

Boards have seen the demos and read the headlines, and now the question is sharp: where's the return? Leadership wants AI delivering real gains across the software lifecycle, and quickly, with the business case to prove it. At the same time, nobody is lowering the bar on security, compliance or data protection. One leaked customer dataset undoes a year of productivity wins. The team in the middle has to deliver both, often at once, with no established playbook for either.

What works: make the two goals pull in the same direction instead of against each other. Start where the return is obvious and the data risk is low, and measure what actually changes: cycle time, review turnaround, time from ticket to merge. Real numbers buy you the credibility to be strict where it matters. Then be honest that security and data protection are what let you scale, not what slow you down. The organisations that get an agent into production safely once can do it fifty more times. The ones that rush and get burned spend the next two years asking permission.

2. How do you govern AI when models and tools change faster than policies?

Traditional governance assumes stable ground. Write the standard, add a review gate, check work against it. That breaks with agents. Models change behaviour between versions, features land every few weeks, and there's a fast-growing open-source ecosystem of tools and plugins that no small team can fully test and verify. By the time a policy is written, the thing it describes has moved.

What works: stop governing specific tools and start governing principles and interfaces. Decide what an agent may access, what it may never touch and what has to be logged, and let those rules survive whichever model or plugin is in fashion this month. Pair that with a curated marketplace and a lightweight path for assessing new things, so the default answer to “can we try this?” is “yes, through here” rather than silence.

3. What happens when autonomous agents expose hidden technical debt and access sprawl?

Agents are brutally efficient at exposing what was already wrong. Hand one a developer's cloud credentials to fix a Terraform issue and it inherits everything that a developer can reach, including the over-broad role granted years ago that nobody remembers. Point it at a codebase with three ways of handling authentication and it'll cheerfully pick one, or invent a fourth. Connect it to a data platform where service accounts cross environment boundaries and it will cross them too, faster and more thoroughly than any person would.

None of that is the agent's fault. The tech debt, the access sprawl and the gaps in cloud governance were already there. Agents just stop letting you ignore them.

What works: treat this as the most honest audit you'll ever get, and act on it. Fix identity and access before you connect agents to anything sensitive. Sandbox properly. Put the strictest controls around personal data and data in general, and be relaxed almost everywhere else. Companies that do this find agents become the business case for cleaning up things they'd been putting off for years.

4. Is agile still the right model when agents write and review most of the code?

Is agile still the right model? Do we still need tickets? What's a human for in a pull request an agent wrote and another agent reviewed? Most organisations are asking these questions and finding no standard answers, because there aren't any yet.

What works: move the human left. The highest-value thing an engineer does now is make sure the work is well specified before the agent starts: a properly refined ticket, then a plan the agent writes and a human review. Only once the plan is agreed does the agent change code. This cuts against the “agents will kill Jira” narrative. A well-refined ticket used to be admin; now it's one of the few places you can actually steer the outcome.

Then pilot the rest. Code review is a good example of how to do that. One approach I'm currently testing uses two capable but different models from the same vendor. The first does a full review using a code-review skill and must end with a clear verdict: safe to merge, or not. The second does an independent pass and produces its own report. The human reads both, reads the PR description and the reasoning for the change, and might open the diff. It raises fair questions: do models from one vendor share blind spots? Probably some. But cross-vendor review has its own costs. Many companies only have access to one provider, and models from different vendors can disagree indefinitely, leaving a PR bouncing between reviewers that never converge.

The point isn't that this pattern is right. It's that someone has to run these experiments, decide what “safe to merge” means, define when a human must read the diff, and turn the answers into guidance people will actually follow. That's governance work most organisations have never had to do before, and it's some of the most interesting engineering work I've done.

5. Where do you enforce quality when humans stop reviewing code line by line?

When humans stop reviewing code line by line, review becomes a confirmation, not a safety net. Quality has to be shaped much earlier.

What works: put your governance in the harness. What matters most is that the agent has rich context about the system it's working in, a well-built set of skills and hooks around it, and that it's constantly steered towards the target architecture. That's where policy lives now: in what the agent knows, what it's allowed to do and where it's pointed before it writes a single line. If you've done platform engineering, you'll recognise this. It's guardrails over gatekeeping, applied to agents.

6. How do you scale AI governance without becoming a central bottleneck?

With that remit and a small headcount, something gives. My worry is that teams try to control all of it centrally and end up as a bottleneck everyone routes around.

What works: a central team that owns the paved road (model access, platform guardrails, the plugin marketplace) and leads on ways of working, with engineering teams building their own harnesses on top using that guidance. Draw one hard line around data and keep it simple. The exception is if your data governance is already excellent and independently audited, in which case you've earned the right to be more relaxed there. Everywhere else, give people room. Developers want to move fast, and you want them exploring and building things you haven't thought of. The hardest part of the job is managing expectations on both sides of that line, and staying genuinely close to security, FinOps and architecture so you're solving problems with them rather than defending against them.

Food for thought

Will small errors slip past AI reviewers and compound into something expensive? Yes, almost certainly some will. The answer isn't to hope they don't. It's to make review and refactoring small and frequent, with agents doing much of the clean-up as they go, rather than waiting for the eventual mess and then paying for it all at once.

How do humans cope with review fatigue as volume climbs, and is the answer really another agent? Ask it the other way round: what's safer, a fatigued human or a couple of well-harnessed agents? A tired person skimming their twentieth PR of the day may well make more mistakes than a second model would. That doesn't mean removing humans. It means being honest about where human attention is scarce and spending it where it actually changes the outcome.

I have working answers to some of this and expect several to change within months. That's not a reason to wait. It's a reason to start learning now, deliberately, while the stakes are still manageable.

Riverbanks

Before I became a dad, someone gave me a piece of advice. Children are like a river. Your job is to make sure the banks are solid enough that it doesn't flood, but not so high and narrow that you choke the flow.

I haven't found a better description of this work. Build a bank firm where the water is dangerous. Keep them low where it isn't. Then let it run, and enjoy watching where it goes.

If you're standing up an agentic engineering capability and any of this sounds familiar, I'd be glad to compare notes. At Crosstide, this is what we do. Get in touch.