Is the outcome the missing link?
Managed AI platforms are getting good at the how: agents, connectors, identity, guardrails. What they can't tell you is what any of it was for. A hypothesis: the missing link is the definition of an outcome, and a Work Pack is what that looks like written down.
There’s a gap in how we’re building AI platforms.
Managed platforms for AI are getting good at the how. Managed agents that run unattended. MCP connectors into systems of record. Identity inherited, data scoped, models approved and paid for. Skills and plugins a team installs in one go. A road like that is how a business transforms with AI.
Most platforms can tell you what agents exist, who owns them and what they touched, but very few can tell you what any of it was for. Nobody has told the platform what “closed” means: the condition that has to be met before something counts as done. So when you ask whether the new customer is onboarded, the campaign has launched or the month has closed, it can’t answer. But a road needs somewhere to go.
My hypothesis is that the missing link is a definition of the outcome, not another agent or connector.
I’m horrible at naming things, so I’ve been calling it a Work Pack, and it comes down to one line:
One outcome. One owner of it. Every step has a slot for an agent.
A Work Pack defines a piece of business work end to end, across every team it touches, and then runs it. What done means and how it gets done live in separate halves, so you can see who answers for the result and who answers for how it runs.
Work doesn’t stop at the team boundary
Here’s the scenario the rest of this post runs on. A CVE is published against a library your web app depends on.
When is it fixed?
…
Ask engineering and it’s fixed when the pull request merges.
But the organisation can’t say it’s closed until a lot more has happened: the transitive dependencies need to be patched too, not just the direct one, and nothing end-of-life is left behind. Anything that can’t be fixed is a signed exception, not a forgotten ticket. Legal has checked the disclosure and contract duties, the fix has survived a pen test, and the threat model reflects the change.
And if the pen test turns up something new, that’s a new finding, and the line starts again.
That’s seven teams: security engineering, engineering, platform, governance, legal, security testing and security architecture. One outcome.
Each of those teams has its own tools, and more and more of them have their own agents. Engineering has a dependency-bump agent. Security has a scanner wired into everything. Each team automates its own step, and the work still falls through the gaps between them, because nobody owns the whole line. Every team can say its part is done while the vulnerability stays open.
A Work Pack is the whole line, written down once, with someone who answers for it.
Work Pack · outcome
A reported vulnerability is closed across the organisation, with evidence each team can stand behind.
- Answers for the result
- Governance, risk and compliance lead
- Answers for how it runs
- Platform engineering lead
- Security engineeringFinding raisedConnectorScannerGate wired:Finding logged with severity
- EngineeringPatch direct dependencyManaged agentDependency bumpGate wired:PR merged, build green
- EngineeringPatch transitive dependenciesPersonOn-call engineerGate wired:Lockfile scan clean
- PlatformEnd-of-life checkOpen slotGate unproven:EOL report attached
- GovernanceException sign-offPersonGRC analyst+ Add-on · Personal agentException drafterGate wired:Signed exception, or none needed
- LegalLegal sign-offPersonCounselGate wired:Sign-off recorded
- Security testingPen testPersonPen test partnerGate wired:Pen test report
- Security architectureThreat model refreshedOpen slotGate unproven:Model version bumped
Define, execute, measure
In the graphic above, two open slots only show up because the definition of the work is kept apart from whoever does it, and the two get checked against each other. Why? You have to start thinking of a pack as three legs.
Define is the factory (AI-DLC / Software Factory) leg: the outcome, what done looks like, and the gate each step has to pass. It’s owned by the outcome owner, one person who answers for the result across every team involved.
Don’t get me wrong, this isn’t a replacement for the AI-DLC. It’s something that works with it.
Execute is the platform leg: the steps, run by agents, skills, connectors or people, each reporting back at its gate. It’s owned by the technology owner, one person who answers for the agents, skills and connectors the pack runs on.
Measure is two numbers, one for each owner. Throughput is what ran, and the technology owner answers for it. Trust is whether every gate came back with evidence, and the outcome owner is accountable for it.
Define · owned by the outcome owner
- Outcome
- One sentence the business would recognise as done.
- Done when
- The conditions every team can check against.
- Gates
- The evidence each step has to hand back.
The pack
Execute · owned by the technology owner
- Steps
- One per team the work crosses.
- Runners
- An agent, a skill, a connector or a person in each slot.
- Reporting
- Every gate reports back to the outcome owner.
The split is the same one from the participation gap. The business writes the top half in plain language. Engineering and the agents own the bottom half. Neither has to understand the other’s half to do its own.
Two owners, not one, because they answer different questions. If the vulnerability isn’t closed, that’s the outcome owner’s problem. If the dependency-bump agent keeps opening broken pull requests, that’s the technology owner’s. Blur them and every failure becomes an argument about whose it was.
The leg the platforms are missing
Look at the execute leg again. Agents, skills, plugins, connectors, identity, guardrails, a catalogue of what exists. That’s a managed AI platform. The platforms are building the bottom half, and they’re building it well.
I haven’t seen a managed AI platform build the top half. The platform knows the dependency-bump agent exists, what it can touch and what it costs. It doesn’t know that agent is one step of eight, that six other teams are involved, or that the work isn’t done until legal has signed. So it measures what it can see: agents running, tokens spent, pull requests opened, which is activity rather than progress.
What’s missing is something that ties that activity back to what the business asked for.
Give the platform a Work Pack and it gets the rest:
- What the work is for. The outcome, in words the business recognises.
- Who answers for it. One named owner across every team.
- Where each agent fits. The slot it fills, and the team that owns it.
- What proof it owes. The gate it has to pass.
- What’s missing. The open slots, on one page.
A catalogue lists what exists and a receipt records what an agent did. Only the pack tells you whether that was the job.
None of this is new outside AI or anything revolutionary, to be honest. Change approvals, release gates in CI, supply-chain attestations and audit evidence tools all name a gate and ask for proof, and most of them have been around for years. What’s new is that the “runner” in a slot can now be an agent, and the AI platforms are being built without that layer on top.
The spec
Written down, a pack is short. It’s at the core of Belay, the platform I’m building, and this is a sketch of the vulnerability one:
pack:
id: vulnerability-remediation
outcome: >
A reported vulnerability is closed across the organisation,
with evidence each team can stand behind.
done_when:
- Direct and transitive dependencies patched
- End-of-life components replaced or excepted
- Exception and legal sign-off recorded
- Pen test passed, threat model current
owners:
outcome: grc-lead # answers for the result
technology: platform-lead # answers for how it runs
steps:
- id: finding-raised
team: security-engineering
runner: { kind: connector, ref: scanner }
gate: finding-logged-with-severity
- id: patch-direct
team: engineering
runner: { kind: managed-agent, ref: dependency-bump }
gate: pr-merged-build-green
- id: patch-transitive
team: engineering
runner: { kind: person, ref: on-call-engineer }
gate: lockfile-scan-clean
- id: end-of-life-check
team: platform
runner: { kind: open }
gate: eol-report-attached
- id: exception-signoff
team: grc
runner: { kind: person, ref: grc-analyst }
gate: signed-exception-or-none-needed
- id: legal-signoff
team: legal
runner: { kind: person, ref: counsel }
gate: signoff-recorded
- id: pen-test
team: security-testing
runner: { kind: person, ref: pen-test-partner }
gate: pen-test-report
- id: threat-model
team: security-architecture
runner: { kind: open }
gate: model-version-bumped
report_to: outcome-ownerRead the top half and you know what done means. Read steps and you know who’s involved, what runs each step today, and what each one has to prove. Nothing in it says which model, which prompt or which tool. That lives with whatever fills the slot.
Each gate here is only a name. In a real pack it would point at the check that proves it, whether that’s the scan, the signed record or the report, and say who’s allowed to accept it.
A CVE lands
Now run it. Say the CVE from the start is against a UI library the storefront ships. It’s rated critical, and the vulnerable code isn’t on a server you control. It’s in the JavaScript bundle running in every customer’s browser.
Nobody types anything. The scanner connector picks it up, and that’s the input:
“Critical CVE in a UI library the storefront ships.”
- 01Security engineeringThe pack opensA finding against the storefront, with severity and affected versions. The outcome owner can see it from the first minute.UnderneathConnector: the scanner logs the finding and starts a run of the vulnerability pack.
- 02EngineeringThe direct fixA pull request bumping the library, build green, waiting for a reviewer.UnderneathManaged agent: dependency bump, started by the finding. A person still approves the merge.
- 03EngineeringThe transitive fixNothing else in the lockfile still pulls in the old version.UnderneathPersonal agent: an engineer's own Claude Code setup with a lockfile skill.
- 04PlatformEnd-of-life checkNobody is in this slot, so it lands with the outcome owner as a gap instead of being skipped quietly.UnderneathOpen slot.
- 05Governance and legalThe sign-offsGovernance records that no exception is needed. Legal checks whether customers need telling.UnderneathPeople, with the analyst's exception drafter riding along as an add-on.
- 06Security testing and architectureThe retestThe partner retests the storefront. The threat model slot is open, so it shows as a second gap.UnderneathPerson: pen test partner. Threat model: open slot.
A connector, a managed agent, an engineer’s own Claude Code setup, three people and an add-on did the work, across five teams, with two more teams’ steps waiting on an open slot. Nobody had to call a meeting to hand it from one team to the next. The input landed on the pack, each slot did its part, and each gate reported back to one person.
The two gaps showed up on day one, not in next year’s audit.
There’s a frontend wrinkle too. For a service you run, merged and deployed is close to fixed. For a frontend, the vulnerable code can sit in CDN caches and in browsers that haven’t reloaded. A team that ran this pack a few times would probably tighten the direct-fix gate from “PR merged, build green” to “new bundle served, old version gone”. That’s a change to the definition, so it’s the outcome owner’s call, and every run after it gets the stricter gate.
Where it runs
Four kinds of runner did the work in that run, plus an add-on. That’s what the runner field is for.
Every step is a slot. The gate belongs to the pack: it’s part of the definition, and the outcome owner agreed it. The runner belongs to the team that owns the step. Today it might be a person. Next quarter it might be an agent. The gate doesn’t care, as long as the evidence comes back.
An agent in a slot doesn’t have to be something deployed. It’s whatever does the work, and the spec says what kind it is:
- Personal agent. Someone’s own Claude, Cowork or Claude Code setup. It runs when they run it, and nothing gets deployed.
- Skill. A packaged set of instructions any of those setups can pick up.
- Plugin. Skills, commands and hooks bundled together, so a team installs the whole step in one go.
- Managed agent. Runs unattended and listens for events. A finding lands, and it starts.
- Connector. An MCP server into a system of record, so the step can read and write where the evidence lives.
- Person. A human does it and records the evidence. Still a valid runner, and often the right first one.
Each slot also says who brings it, a name or a team, so the technology owner knows who to call when it breaks.
Apart from the person, everything that fills a slot is built from the same parts: a model, skills, plugins, a managed agent or an MCP connector. The pack doesn’t care which of them is in a slot. A step can start as a personal agent on one engineer’s laptop, become a plugin the whole team installs, and end up as a managed agent that runs on every finding, and the definition never changes.
The transitive fix in the CVE run is that story halfway through. It used to be the on-call engineer. Now an engineer runs it through their own Claude Code setup, and only that slot changed:
- id: patch-transitive
team: engineering
runner:
kind: personal-agent # was: person
ref: lockfile-fixer-skill
brought_by: payments-squad
gate: lockfile-scan-clean # unchangedNobody outside engineering had to agree to it, though the technology owner still needs to know what it runs as and what it can touch. Governance doesn’t need to know what a lockfile is. Legal doesn’t need to review the agent. The outcome owner sees the same gate return the same evidence, just sooner. And if the agent turns out worse than the person, it’s one slot back.
That’s how agents get adopted without a big-bang programme: one slot at a time, wherever a team is ready, with the definition holding still underneath them. It’s the same build-as-you-go idea, applied to the whole business. The skills and agents are what fill the slots. The pack is where they’re going.
Personal agents as add-ons
Not every agent needs to own a slot. Plenty of the best ones are personal: someone’s own setup that makes their part of the job faster, which nobody else depends on.
A pack can take those as add-ons. An add-on rides alongside a step and helps whoever runs it. It doesn’t own the gate and it isn’t in the definition of done. In the CVE run, the governance analyst still signed off, but their own agent drafted the record from the finding and past decisions like it:
- id: exception-signoff
team: grc
runner: { kind: person, ref: grc-analyst }
addons:
- kind: personal-agent
ref: exception-drafter
brought_by: grc-analyst
gate: signed-exception-or-none-neededAn add-on can’t change the gate, and the step has to work without it. If the analyst leaves and takes their agent with them, the pack still runs, just slower.
What add-ons buy you is visibility. Instead of personal agents built in secret, they’re declared on the step they help, and the technology owner can see which ones are pulling their weight. That makes them the natural on-ramp. An add-on that keeps working for one person is the obvious candidate to become a skill or plugin the whole team installs, and then the runner in the slot. Add-on first, slot second.
Across the boundary
The gate is also what lets a pack cross teams without turning into a meeting.
Each team owns its step and nothing else. It can change how that step runs, swap a person for an agent, swap one scanner for another, move the work to a vendor, without asking anyone, provided the gate still gets its evidence. The gate is the contract between teams, in the way an API is the contract between services. You can rebuild everything behind it as long as you keep the promise.
It works across business units too. A second region with its own legal team and its own governance lead doesn’t need a second pack. It needs a few overrides:
pack:
extends: vulnerability-remediation
owners:
outcome: emea-grc-lead
steps:
- id: legal-signoff
team: legal-emea
runner: { kind: person, ref: emea-counsel }Same outcome, same gates, different people in some of the slots. The same CVE can run in both regions, and they can compare like with like, because they’re measuring the same thing.
What teams will need to think about
Name the owner first
The hardest line in the spec is outcome: grc-lead. Naming one person who answers for a result across seven teams is an organisational decision, not a technical one. If nobody will put their name there, you’ve learned something important about the work, and no platform will fix it for you.
Agree the gates, then leave the runners alone
Gates are the contract. Tightening one, like the frontend fix gate, is the outcome owner’s decision, and it should be versioned like any other contract so a run can say which definition it ran against. Runners are the opposite. The team that owns the step should be able to change them without asking anyone.
Treat open slots as the honest part
Every open slot and every unnamed owner is a place where the pack can’t yet prove the outcome. Before you write a pack, those holes exist anyway. They’re just invisible, spread across teams who each believe someone else has it covered. Writing the pack doesn’t fix them, but it puts them on one page where the outcome owner can see them. I’d rather have a pack that shows two open slots than a process diagram that implies there are none.
Measure trust, not just throughput
Most AI measurement stops at throughput: how many pull requests the agent opened, how many hours it saved. A pack still counts that. It’s the easy number. The number that matters is trust: did every gate return evidence? A fast run with three gates missing their evidence isn’t done, however quick it was. As I said in skills being the vehicle, the pack is the unit you measure.
And when an agent returns the evidence, someone has to decide whether to believe it. A clean lockfile scan is easy to check. A threat model being “current” isn’t. Some gates will need a person to look, even when an agent did the work.
Know who each agent is acting as
The dependency-bump agent opens pull requests on the storefront as someone. The exception drafter reads governance records as someone. The pack says which slot an agent fills. The platform still has to answer who it is, what it can touch and who pays for it. That’s the road, and a pack needs one underneath it.
Expect it to leave engineering
A CVE is a useful example because the teams are easy to name, but nothing in the shape is about security. A campaign launch crosses marketing, brand, legal, data and the web team. Month-end close crosses finance, the business units, payroll and audit. Contract to signature crosses sales, legal, finance and whoever owns the customer record.
Each has an outcome someone would recognise as done, teams who each own a step, and slots where an agent could take on some of the work. Someone in finance types “the close is late because of intercompany”, and it lands on the step it’s about, with the team that owns it, against the gate it’s failing.
Final thought
Managed AI platforms are solving the how: where agents run, what they can touch, who’s allowed to build them. That’s necessary, and it isn’t enough. Without a definition of the outcome, a platform is a well-governed way of being busy.
A Work Pack isn’t an agent or a platform, and it isn’t the engine that runs the steps. It’s the definition that sits on top of one: one outcome, one owner of it, and a slot at every step for whoever runs it. The agents are an implementation detail, which is exactly why they’re easy to swap.
Is it the missing link? I think so. If the platforms start treating outcomes as a first-class thing, with owners, gates and evidence, then I was right and someone filled it. If they can prove business impact without one, I’m wrong, and I’d love to see how.
Write the outcome first. Name the owner. List the teams the work crosses and the evidence each has to hand back. Mark the slots you can’t fill yet. That page is worth more than any agent you could plug into it, because it’s what tells you whether the agent did its job.