Three Things Your Platform Needs Before Agents Touch Production

Most engineering teams now have an agent that works in a demo. Far fewer have one they'd trust to change a production config at 2 a.m. with nobody watching. What usually separates the two is the platform underneath.

‍

On November 2, Tensure co-founders Justin Billig and Dan Rye joined platformengineering.org for a live session on exactly that gap. Their argument: agentic engineering only works when the platform can support autonomous action safely, and that comes down to three capabilities. A controlled action layer. Identity and guardrails. A feedback loop.

‍

Here's what each one means in practice, and why you need all three.

Your platform was built for people

Think about how a change reaches production today. A developer opens a pull request, a teammate reviews it, the pipeline runs, someone approves the deploy. Along the way, human judgment quietly fills in a hundred unwritten rules. Nobody drops a table in the shared database. Nobody restarts every pod in the cluster at once. If something looks off, a person stops and asks.

‍

Agents don't have that instinct. They do what their access allows, quickly, and as many times as they're told. Every rule your team follows by habit has to become something the platform enforces. That's the work.

1. A controlled action layer

An agent shouldn't be calling whatever API or CLI it can reach with a borrowed credential. It should act through a defined set of operations the platform owns: deploy this service to staging, open a pull request against this repo, scale this deployment within these limits.

‍

If you've built golden paths for developers, this is the same idea pointed at a new kind of user. Each action has known inputs, gets validated before it runs, and can be reversed where possible. The payoff is that you can understand what an agent is able to do by reading a list, instead of auditing every prompt it might receive.

‍

This layer is also where risk tiers live. Low-risk actions, like generating tests or updating documentation, can run on their own. High-risk ones, like a production deploy or a change to security-sensitive code, route to a human for approval no matter who or what initiated them.

2. Identity and guardrails

Every agent needs its own identity. Not a shared service account, and definitely not a developer's personal token. Give each agent scoped, short-lived credentials and only the permissions its job requires. Then put hard limits around it: rate limits, spend limits, and a small blast radius if something goes wrong.

‍

Here's a useful test. When something changes in production, can you tell within a minute which agent made the change, under whose authority, and why? If the answer is "we'd have to dig through logs," you aren't ready to expand agent access. For teams in banking, insurance, or payments, this isn't optional. Your auditors will ask the same question, and "the AI did it" won't satisfy them.

3. A feedback loop

An agent that runs a deploy and gets an exit code of zero will happily report success. Whether the deploy actually worked is a different question, and the agent can only answer it if the platform tells it.

‍

That's the job of the feedback loop: observability, tests, policy checks, SLOs, and audit data, all available to the agent after it acts. With it, an agent can see that error rates climbed after its change, roll back, and flag a human. Without it, you find out from your customers.

‍

The feedback loop does something else, too. It produces the evidence you need to decide when an agent has earned more autonomy. Every action it took, what happened next, and how often it was right.

Miss one and the other two can't carry it

These three capabilities depend on each other. A controlled action layer without identity tells you what can happen but not who did it. Identity and guardrails without feedback give you an agent that fails safely and silently. Feedback without a controlled action layer gives you excellent data about a mess.

‍

Your weakest capability sets the ceiling on how much autonomy you can safely grant. Teams that pour effort into one and skip the others end up with pilots that look great in a demo and stall before production.

Where to start

You don't need to build all of this for every workflow at once. Pick one that's valuable and low-risk: diagnosing CI failures, generating tests, deploying to non-production environments. Build the action layer, identity, and feedback loop for that single path. Run it, measure it, and expand from there.

‍

Just don't start with unsupervised production deploys, regulated business logic, or legacy systems you can't roll back. Autonomy should be earned one workflow at a time.

‍

Watch the full session. Justin and Dan go deeper on each requirement in the 45-minute recording: 3 platform requirements for agentic engineering.

‍

Find out where you stand. Tensure's agentic engineering maturity assessment shows which of these capabilities your platform already has and which ones are holding your agents back. Learn more about how Tensure helps teams build agentic engineering platforms.

‍