KPMG's Global AI Pulse has the number every software leader should sit with:
95% of organizations have an AI strategy. Only 8% report established ROI.
That gap is not about ambition. It is not about access to models. It is not even about whether teams are using AI.
Most teams are using AI.
The problem is that AI is being added to workflows that were never redesigned for agentic execution. Tickets still stall. QA still finds context too late. Docs still drift. Release still depends on someone remembering the checklist. The AI writes code, but the system around the code still does not ship reliably.
That is the real ROI gap.
AI can write code. Code is not a shipped solution.
Short answer
AI ROI shows up when agents operate inside a real delivery system:
- Work starts from a clear card.
- Context lives in a shared vault.
- Agents have defined roles.
- Deterministic tools handle repeatable execution.
- Humans approve the gates that matter.
- QA, docs, and release are part of the same workflow.
- Every handoff is visible.
- Every outcome is measurable.
Without that system, AI creates more activity. Not more delivery.
The problem is not AI adoption. It is execution.
KPMG's report says organizations plan to invest an average of US$186 million in AI over the next 12 months. It also says a small group of AI leaders, about 11%, is pulling ahead by operating AI as an integrated enterprise-wide system.
The useful lesson is simple:
Spending more on AI is not the same as getting work shipped.
That matters for engineering teams because AI adoption usually starts in the wrong place. A developer gets a coding assistant. A PM uses AI to draft tickets. QA uses AI to summarize failures. A manager asks AI for a status report.
Individually, each person gets faster.
The team does not necessarily move faster.
The bottlenecks are still in the handoffs:
- Idea to ticket.
- Ticket to plan.
- Plan to implementation.
- Implementation to test.
- Test failure to fix.
- Fix to docs.
- Docs to release.
- Release to memory for the next card.
If those handoffs are still manual, invisible, and inconsistent, AI has not changed the delivery system. It has just made isolated tasks faster.
That is why teams feel more productive but still miss dates.
AI pilots are easy. Agentic delivery is hard.
A pilot is forgiving.
You pick a narrow task. You feed the model clean context. You watch the output carefully. Everyone knows it is a demo.
Production is different.
Production has messy tickets, unclear ownership, half-updated docs, failing tests, missing acceptance criteria, Slack context, legacy decisions, release constraints, and people who do not have time to babysit an AI assistant.
That is where agentic workflows break.
The failure mode is predictable:
- The AI gets a vague ticket.
- It makes reasonable assumptions.
- The implementation looks plausible.
- QA finds a mismatch.
- The team realizes the real context was in Slack, Confluence, an old PR, or someone's head.
- The human has to stitch everything back together.
That is not an AI model problem.
That is a workflow architecture problem.
What AI StackWorks means by an execution layer
An execution layer is the system between "the AI can help" and "the work actually shipped."
For AI StackWorks, that layer is built around three ideas.
1. The card
The card is where work happens.
Every card carries the plan, acceptance criteria, agent handoffs, implementation notes, QA results, release status, and the timeline of what happened. It mirrors the board your team already uses: Jira, Linear, or GitHub Projects.
The card matters because agents need a place to work that humans can inspect.
Not a hidden chat.
Not a private prompt history.
Not a one-off local session.
A card.
2. The vault
The vault is where context lives.
Specs, architecture notes, decisions, runbooks, and lessons from shipped work should not disappear after a ticket closes. They should become reusable memory for the next card.
This is where many teams lose the compounding value of AI.
The agent learns something during the work, but the organization forgets it.
A living vault fixes that.
3. Human gates
Agents can move work. Humans hold the gates.
That means the PM agent can draft a plan. The engineering agent can open a PR. The QA agent can run validation. The release agent can prepare the checklist.
But your team approves the transitions that matter.
AI proposes. Humans decide. Tools execute.
That is how you get speed without losing control.
Why ROI gets lost between the IDE and the board
Most AI coding tools stop too early.
They help in the IDE. They help with a function, a test, a refactor, or a bug explanation.
Useful? Yes.
Enough? No.
The work still has to move through the system:
- Is the ticket scoped?
- Does the implementation match the acceptance criteria?
- Did tests run?
- Did QA understand the why?
- Did the docs update?
- Was the release approved?
- Did the board reflect the real status?
- Did the team learn anything reusable?
That is where ROI is either captured or lost.
If AI stops at the IDE, your team still owns the coordination burden.
If AI works through the board, the system starts to change.
The operating model engineering teams actually need
Here is the practical model.
1. Start with the workflow, not the model
Do not start with "Which LLM should we use?"
Start with the delivery path.
Pick a real workflow:
- Jira triage.
- Bug fix from intake to PR.
- Feature ticket from plan to release.
- Infrastructure request.
- Documentation update.
- QA failure loop.
- Release checklist.
- Weekly engineering status report.
Then ask:
- Where does the work start?
- Who owns the decision?
- What context does the agent need?
- What tools must run deterministically?
- What gates need human approval?
- What output proves the work is done?
The model choice comes later.
2. Separate judgment from execution
AI is good at judgment.
It can read context, compare options, draft plans, identify risks, summarize tradeoffs, and recommend next steps.
But repeatable execution should be handled by deterministic tools wherever possible.
A script should run the tests.
A CLI should validate the ticket.
A GitHub action should check the PR.
A structured API should move the card.
A release checklist should produce the same result every time.
AI judges. Tools execute.
That is the pattern behind reliable AI workflows.
For a deeper look at this split, see Stop Sending Everything to the AI.
3. Make handoffs visible
Hidden handoffs kill agentic workflows.
If a PM agent creates a plan, the engineering agent needs to know what changed. If the engineering agent opens a PR, QA needs the acceptance criteria and the implementation notes. If QA fails, the fixing agent needs the exact verdict, not a vague summary.
Every handoff needs:
- Input.
- Owner.
- Output.
- Status.
- Gate.
- Trace.
That should live on the card.
4. Keep context shared
N people with AI is not the same as one team with AI.
If each person has a private assistant with private context, the team does not compound. You get isolated productivity and fragmented knowledge.
Shared AI systems need shared context:
- Product requirements.
- Architecture decisions.
- Previous PRs.
- Test results.
- Runbooks.
- Release notes.
- Customer constraints.
- Team conventions.
That is what the vault is for. For more on the team-level shift, see From Solo Vibes to Shared AI Systems.
5. Measure shipped outcomes
Do not measure AI ROI by prompt volume.
Do not measure it by how many developers installed a tool.
Measure the work:
- Cycle time.
- Blocked tickets.
- QA rework.
- PR review time.
- Lead time to release.
- Documentation freshness.
- Triage backlog.
- Number of tickets shipped end-to-end by the agent squad.
- Human interventions per card.
- Reopened work.
If the board does not move, ROI is not there yet.
The AI execution checklist
Before you scale AI agents, check the basics:
- Is there a clear workflow?
- Is there a card where work is tracked?
- Is there a shared vault where context lives?
- Are agent roles defined?
- Are tool boundaries defined?
- Are human gates explicit?
- Are test and QA results attached to the work?
- Are docs updated as part of the workflow?
- Are release decisions visible?
- Are outcomes measured on the board?
If the answer is no, adding more agents will probably create more noise.
Not because agents are useless.
Because the system is not ready for them.
Common mistakes
Mistake 1: Buying more AI tools instead of fixing the workflow
More tools can make the problem worse.
You get more chats, more generated code, more private context, more partial outputs, and more things for humans to reconcile.
The question is not "Which AI tool should we buy?"
The question is "Where should agent work live so the team can trust it?"
Mistake 2: Treating AI as a developer productivity feature only
Developer productivity matters.
But the work does not stop at code generation.
Most delivery friction lives outside the code editor: intake, scope, handoffs, QA, documentation, release, and team alignment.
If AI only improves code writing, the rest of the system still limits throughput.
Mistake 3: Skipping human gates
Fully autonomous delivery sounds clean in a demo.
In real teams, trust comes from control.
Human gates are not a failure of automation. They are how the team protects quality, security, customer impact, and release confidence.
The point is not to remove humans.
The point is to stop wasting human attention on low-value coordination.
Mistake 4: Letting docs stay stale
Agents need context.
If your docs are stale, the agent starts from bad memory.
That is why documentation cannot be a cleanup task after shipping. It has to be part of the delivery workflow. The vault updates because the card shipped.
Mistake 5: Measuring AI usage instead of shipped work
Usage is not ROI.
A team can use AI every day and still have the same blocked tickets, same QA loops, same stale docs, and same release drag.
Measure what changed in the system.
What engineering leaders should do next
Pick one workflow.
Not ten. One.
Good starting points:
- Jira or Linear triage (see Automating Jira Triage with AI Agents).
- A small feature from ticket to PR.
- A bug fix from intake to QA.
- Documentation update after code changes.
- Weekly engineering report from board activity.
- Release checklist coordination.
Then map the agent squad:
- PM agent: clarifies the card and drafts the plan.
- Engineering agent: implements and opens the PR.
- QA agent: validates against acceptance criteria.
- Release agent: prepares the release checklist and updates the vault.
Add human gates:
- Approve the plan.
- Approve the PR.
- Approve release.
- Approve vault updates if needed.
Then measure:
- How long did the card take?
- Where did it block?
- How many human interventions were needed?
- Did QA understand the why?
- Did docs update?
- Did the next card start smarter?
That is how agentic workflows become real.
Not by adding another assistant.
By building a shipping system. Learn more about the product, how a Kickstart engagement works, or the team training program.
FAQ
Why do AI agents fail to create ROI?
AI agents fail to create ROI when they operate outside the delivery system. If agents do not have shared context, clear roles, deterministic tools, human gates, and visible workflow ownership, they create activity without predictable outcomes.
What is an AI execution layer?
An AI execution layer is the workflow system that lets agents plan, build, test, document, and ship through the tools a team already uses, such as Jira, Linear, GitHub Projects, Slack, Confluence, and GitHub.
How is AI StackWorks different from a coding assistant?
A coding assistant helps an individual write code. AI StackWorks coordinates agent work across the software delivery lifecycle: intake, planning, development, QA, docs, release, and shared memory.
Why does shared context matter for AI agents?
Shared context prevents each agent or team member from working with a different version of reality. A shared vault gives agents access to specs, decisions, docs, test results, and lessons from previous work.
Do AI agents need human approval gates?
Yes, for most production engineering workflows. Human gates keep the team in control of scope, quality, security, release decisions, and customer impact while agents handle the coordination and execution work around those gates.
How should engineering teams measure AI ROI?
Measure shipped outcomes, not AI usage. Useful metrics include cycle time, blocked tickets, QA rework, PR review time, release lead time, documentation freshness, triage backlog, and tickets shipped end-to-end by the agent squad.
Conclusion
The next phase of AI value will not come from teams that add the most tools.
It will come from teams that redesign how work moves.
The model matters. The prompts matter. The agents matter.
But the system matters more.
If AI work does not live on the board, share context through the vault, pass through human gates, and improve measurable delivery outcomes, it is not an execution system yet.
It is another productivity experiment.
AI ROI starts when agents stop hovering around the work and start moving through the workflow.
Ready for an agent squad on your board?
AI StackWorks wires agent squads into Jira, Linear, or GitHub Projects, with shared context, human gates, QA, docs, and release built into the workflow.
Request early access if you want to run it yourself.
Or book a Kickstart call if you want us to wire it in and ship a real feature with you.