Agile software development & agentic AI execution: delivering with agents

From code assistance to agentic AI: four levels

Coding tools evolved in four levels. Chat assistants generate snippets on request. Inline copilots complete code in the editor. Autonomous agents such as Claude Code or Cursor read project files, run bash commands and create pull requests. Orchestrated agent systems distribute work across specialised roles with documented handovers. Each level increases autonomy – and with it the price of an unclear brief.

For product managers, level three is the turning point: from here on, the machine executes for hours what you defined. An agent building in the wrong direction for an hour because the goal was unclear produces an hour of damage. The table below maps the levels and the human's role in each.

Why classic Scrum breaks in AI development

Scrum assumes work can be cut into plannable increments: story in, estimate attached, done by sprint end. Model training and fine-tuning don't comply – they require unpredictable iteration cycles in which an experiment may fail without the sprint failing. Squeeze AI work into classic stories and you get either burst sprints or estimates nobody takes seriously any more.

The answer is not less discipline but an adapted one: spikes instead of stories for experiments, evaluation criteria in the definition of done, delivering and learning cleanly separated. Frameworks like CRISP-ML(Q) give this structure. The deep dive “Agile for AI: sprints that survive model training” shows the adaptations in detail – without sacrificing delivery discipline.

Live view: real-time status instead of sprint-end surprises

In classic agile processes the true state of an implementation often becomes visible only at sprint end, and estimates rest on historical experience that can deviate widely from the current source code. A live view inverts this: real-time progress with context on the actual code, estimates grounded in the codebase, dependencies and architectural hurdles surfacing as they arise – not in the review.

Control stays with the team: developers delegate clearly scoped tasks to agents that build against the spec from the define phase, and intervene immediately on deviations. The result is a controlled delivery of reviewed software – without nasty surprises at sprint end.

The ticket becomes the prompt: writing requirements for agents

A Jira ticket in agentic engineering is no longer a work instruction for humans but a context-complete prompt parsed by AI agents. The 100-word pointer “as discussed, see meeting” doesn't work when the addressee wasn't in the meeting. The ticket operationalises the spec from the define phase: goal, context, acceptance criteria, edge cases – complete enough that an agent can build without follow-up questions.

What this anatomy looks like in detail – including story files and context engineering – is covered in “The anatomy of a Jira ticket for AI product management”. The vocabulary behind it, from epic to cycle, is in the product management glossary.

Model Context Protocol: connecting agents to tools

The Model Context Protocol (MCP) is the open standard through which language models communicate directly with tools such as Jira, Slack or local databases. It eliminates the error-prone manual export-import cycles: instead of copying tickets and pasting results back, the agent reads and writes itself – with defined permissions.

For the build phase, MCP is the lever that makes agentic execution practical: the agent fetches the context it needs from the systems where it lives. For product managers this also means: permissions, data access and audit belong in the spec – who may read what, write what, and never touch what.

The sandwich architecture: deterministic cages for probabilistic systems

Autonomous agents in enterprise use need security architecture, not hope. The sandwich architecture flanks the core model with two control layers: an input guardrail checks every input for prompt injections and accidentally transmitted personal data before it reaches the core model. An output guardrail verifies the response – against hallucinations, against disclosure of confidential system information, against violations of your own policies.

The principle behind it: never trust the model blindly. It is not a safe internal logic component but a system that can interpret any input as an instruction. High-stakes decisions therefore stay with classic code or with humans; regular attack simulations by your own team expose weaknesses before others do.

Security costs latency – every control layer takes time. That trade-off is a product decision, not a technical one: it belongs in the PRD, with thresholds per use case.

PM, data scientist, ML engineer: handovers decide

Empirically, AI features rarely fail on model architecture – they fail on poor handovers, where responsibilities blur between product management, data science and engineering. The build phase is where this friction becomes visible: who defines the evaluation criteria? Who decides when a model is good enough? Who carries the pager when it drifts?

“PM, data scientist, ML engineer: who does what?” delivers the role boundaries that work – and the two launch questions every AI team must answer in writing. The short version: every handover needs an artefact, and every artefact needs an owner.

Autonomy needs standards: the Spotify trap

The Spotify model promises autonomous squads shipping independently. With AI agents, this autonomy without central standards turns into architectural chaos: every team prompts differently, every codebase diverges faster, and token budgets burn in redundant work. Agents scale the effect of every decision – including the bad ones.

Organised alignment is therefore mandatory: shared spec standards, shared context files, central guardrails. “Why the Spotify model fails – even more so with AI agents” draws the lessons from the documented cases – as a warning against boundless agility in the AI era.

Frequently asked questions