Your First Agent Program Should Be One Workflow Wide

Ask an engineering leader how the agent pilot is going and you'll usually get a status report on tooling. Which models they're testing, which IDE plugin won the bake-off, how many seats are provisioned. Ask what shipped to production through an agent last month and the conversation changes shape.

‍

That gap is a scoping problem, not a technology problem. Nearly 41% of platform teams can't demonstrate value within twelve months of starting, according to the State of Platform Engineering Report Vol. 4, and agent programs are inheriting the same failure mode for the same reason. The mandate is too wide to finish and too vague to prove.

‍

The platform engineering community solved a version of this years ago with the minimum viable platform: one golden path, for one persona, end to end, shipped in weeks rather than quarters. The same discipline works for agents, and it needs one more constraint that platform MVPs get to defer.

Scope the slice, not the strategy

A minimum viable agentic slice is one workflow, for one team, from spec through production, with governance in place from the first run.

‍

Every word in that is load-bearing. One workflow, because a workflow is small enough to describe precisely and big enough to prove something. One team, because the second team will have different constraints and you want to learn them separately. Spec through production, because a pilot that ends at a pull request has proven that agents can write code, which nobody doubts, rather than that your organization can absorb what they produce. And governance from the first run, because the retrofit is the part that kills these programs.

‍

That last constraint is where the agentic slice departs from the platform MVP. A platform MVP can reasonably defer high-compliance scenarios and advanced access control to a later phase, on the theory that early adopters are internal, friendly, and few. An agent isn't a friendly internal adopter. It's a non-human actor making changes at machine speed, and if you can't say which agent made a change, under whose authority, with what permissions, and how to reverse it, you don't have a pilot. You have an incident with a delay fuse.

‍

So the floor goes in first: a scoped identity for the agent, short-lived credentials, an explicit list of tools and systems it can reach, a log of everything it did, and a rollback path a human can execute without asking anyone. That's a week of platform work in most shops that already run secrets and identity management properly. It's a quarter of work in shops that don't, which is itself the finding.

Pick the boring workflow

The instinct is to pilot on something visible. Resist it. The best first slice is high enough value that finishing it matters, and controlled enough that failing it costs a morning.

‍

Four questions sort candidates quickly.

‍

Can you write the requirement down completely? Not "the team knows what good looks like," but written, with acceptance criteria someone outside the team could check. If the answer is no, you've found a Business Intent and Requirements gap, and pointing agents at it will produce fast, confident, inconsistent work. That's a real finding, and it's cheaper to learn now.

‍

Can the agent get an environment without a ticket? Self-service environment provisioning is the difference between an agent that works and an agent that waits. If every run pauses for a human to hand it a place to run, you're supervising mechanics rather than judgment, and the supervision costs more than the output.

‍

Can you tell automatically whether the result is correct? Test coverage on the target service is the honest gate here. An agent that can't verify its own work hands you something to review by hand, which puts the bottleneck exactly where it was before.

‍

Can you undo it in one step? Reversibility is what lets you run the slice at speed instead of running it under a microscope.

‍

Workflows that usually pass all four: test generation, CI failure diagnosis, service scaffolding from a template, documentation generation, dependency upgrades, defect remediation on a well-covered service, non-production deployment. Workflows that almost never pass: anything touching regulated business logic, unsupervised production deployment, and legacy systems nobody fully understands. Those aren't off the table forever. They're off the table until the boring slice has shown you what your actual constraints are.

‍

Financial services teams have a useful advantage here, oddly. You already know which systems carry model risk sign-off and change advisory review, and which don't. That map is your pilot selection criteria, already drawn.

Set the degrees of freedom before the first run

Two dials, both set deliberately, both written down.

‍

The first is blast radius: what the agent may touch. Which repositories, which environments, which pipelines, which data. Start narrower than feels useful. A single service, a non-production environment, no access to customer data of any kind. You will widen this, and widening is a decision you get to make once you have evidence rather than a decision you discover you already made.

‍

The second is the human gate. Tensure's Spec-to-Ship loop keeps two stages primarily human: approving the spec before work starts, and accepting the build before it ships. Your first slice keeps both. That's not timidity, it's instrumentation. When the agent produces something wrong, you want to know whether the spec was wrong or the execution was, and you only learn that if a human signed the spec on the way in.

‍

Once the slice is running, cadence tells you where the constraint moved. If the agent finishes in twenty minutes and the accept gate opens on Thursdays, your cadence is weekly no matter how fast the model is. Nothing ships faster than the gate opens. Most teams discover the gate is the thing they need to redesign, not the agent.

‍

That redesign has three settings, and picking one is a scheduling decision more than a technical one. Standard cadence means decisions weekly, which is where most teams already operate and a fine place to start the slice. Accelerated means twice-weekly decisions, and it's the realistic target for an AI-enabled team. AI-native means daily, where the gate has thinned to the point of nearly disappearing. Notice that none of those settings removes the human. They change how often the human shows up. A team that moves from weekly to twice-weekly acceptance roughly doubles the throughput of the same agent without touching the agent, which is the clearest evidence you'll get that the model was never the constraint.

Four problems not to solve yet

Cross-team agent identity governance. You need identity for the one agent in the slice, scoped to the systems in the slice. You do not need the enterprise scheme for how every future agent gets registered, reviewed, and deprovisioned. Design that after you've operated one agent for a quarter and know what the review actually needs to catch.

‍

Platform-wide golden path coverage. Golden paths an agent can traverse without asking permission are the eventual goal, and one path is enough to start. Synchrony's platform team built pre-approved infrastructure-as-code templates well before anything agentic was in scope, and that standardization is exactly what an agent needs to operate without a human translating for it. The templates came one workload at a time.

‍

ROI modeling. You'll be asked. Answer with cycle time on the slice and rework rate on the slice, and say plainly that a single workflow can't support an organization-wide projection. A number you invent in month two becomes the number you're measured against in month nine.

‍

Model selection as a strategic decision. The model will change twice before the slice matures. Build the slice so swapping it is a configuration change, then stop thinking about it.

The second slice is the one that teaches you

A single successful slice proves an agent can complete a workflow in your environment. It doesn't prove the approach generalizes, and the difference matters, because the first slice usually succeeds partly on enthusiasm and the attention of your best engineers.

‍

Pick the second slice for contrast, not similarity. Different team, different service, ideally a different pillar under strain. If the first slice ran on a well-tested service with clear requirements, run the second one somewhere the specs are weaker and watch what the agent does with ambiguity. What breaks the second time is your real roadmap, and it's usually not what the first slice suggested.

‍

Watch three things across both. Rework rate, because rising rework with rising throughput means your specifications are underspecified rather than your agents underpowered. Time spent at the gates versus time spent in execution, because that ratio tells you which end of the loop to redesign. And how much of the run depended on one person knowing something undocumented, because an agent is a very effective auditor of the steps your process never wrote down.

‍

Then widen the dials one notch, in one direction, with the reason recorded. Autonomy is earned, and it's earned in increments you can point at.

‍

Somewhere around the third or fourth slice, the work changes character. You stop running pilots and start running a portfolio, and the questions become platform product questions: who owns the agent configuration, how a team requests a new slice, what the support model is when a run fails at 2am, which slices get deprecated when the underlying service changes. Teams that have already scaled an internal developer platform recognize all of this, because it's the same transition from "we built a thing for one team" to "we run a product with users." The agent is a new kind of user, with unusual demands around identity, observability, and reversibility, and the same operating disciplines apply.

‍

The mistake to avoid at this point is standing up an agent center of excellence that owns every slice centrally. Central ownership of the governance floor, yes. Central ownership of the workflows, no. The team that runs the service knows what correct looks like on that service, and that knowledge is the scarcest input in the whole system.

The slice is a platform test wearing an AI costume

Here's the part worth sitting with. Almost nothing in the plan above is about artificial intelligence.

‍

Scoped identity, self-service environments, automated verification, one-step rollback, written acceptance criteria, a fast approval loop. That's platform engineering, and it was the right answer before agents existed. What agents changed is the tolerance for skipping it. A human developer works around a missing environment by filing a ticket and context-switching. An agent stops, or worse, finds a path you didn't intend.

‍

Which is why teams that already run a mature internal platform tend to move from AI-Assisted development to Agent-Enabled workflows in a quarter, and teams that don't spend that quarter discovering their platform gaps one agent run at a time. Both outcomes are useful. Only one of them was planned. We've written more on what happens when the platform work is skipped entirely in agentic delivery without a platform foundation, and on the specific ways agentic workflows stall in fintech.

‍

So scope the slice this month. One workflow, one team, spec to production, governance from the first run. Ship it, then pick a second slice that makes you uncomfortable.

‍

If you want a read on which pillar will constrain you before you pick the workflow, our agentic engineering maturity assessment scores Platform Engineering, SDLC Operating Model, and Business Intent and Requirements separately and tells you which one is holding the other two down. It takes about ten minutes, and it's a better starting point than a tooling bake-off.

‍