Build Loop
Spec → Slice → Implementation → Review → Release
Review findings improve the spec.LOOPSWORK IN PRACTICE
Jira coordinates the work. Confluence keeps the knowledge. AI agents support delivery.
LoopsWork does not require a dedicated tool. It connects existing systems so that an intended outcome becomes small, actionable specs, changes are verified, and new learning feeds back into the work.
Jira, Jira Product Discovery, and Confluence can map this workflow directly. AI agents can also support research, planning, implementation, review, and analysis.
Tool-agnostic
LoopsWork defines working principles, not software. Jira and Confluence show one way to apply these principles with existing tools. The framework remains technology-agnostic.
LoopsWork does not add another process on top of Jira. It connects existing tools so the Build, Value, and Learning loops work together visibly.
01 / TARGET STATEOne system. Three loops.
Value Loop
Outcome → Measurement → Result → Decision
Impact changes priorities and future work.Learning Loop
Learning → Experiment → Decision → New context
Learning improves the next specs.Build ↔ Value: changes & measurement requirementsValue ↔ Learning: evidence & hypothesesLearning ↔ Build: context & new specs
Humans decide
Jira / Confluence ↔ AI agents
Code / systems02 / JIRA PRODUCT DISCOVERYStart with impact, then define the work
A LoopsWork initiative starts with an intended outcome, not a feature list.
Jira Product Discovery provides a layer above implementation: an initiative links the intended outcome to delivery work in Jira.
- Outcome
- Initiative
- Specs
These fields are one possible card structure. Outcomes and initiatives do not need additional Jira hierarchy levels.
Simplify checkout
- Problem
- Customers abandon checkout too often.
- Desired Outcome
- Reduce checkout abandonment.
- Baseline / Target
- 12,4 % → < 10 %
- Confidence / Investment
- Medium / M
- Measurement checkpoint
- 14 days after release
03 / WORK ORDERThe spec is the work order
The spec is LoopsWork’s central unit of work. It describes what should change, why, under which conditions, and how success will be assessed. Specification-Driven Development provides a shared agreement for people and agents.
LW-142 · Spec · exampleReady
Express Checkout
- Outcome
- More customers complete checkout successfully.
- Change
- Saved address details can be reused.
- Acceptance Examples
Givena signed-in customerWhencheckout is openedThenthe saved address is selected by default.- Constraints
- Preserve guest checkout · keep the existing payment interface
- Relevant Context
- Customer Profile API · DEC-023 · Checkout Architecture
- Expected Value
- Reduce checkout abandonment from 12.4% to below 10%
- Reliability & Observability · optional
- Criticality · monitoring · alert triggers · SLO / expected availability (optional) · failure behavior · dashboard / tool (optional). Keep this short or omit it for low-risk changes. Open the guided template
- Measurement / checkpoint
- Checkout funnel / 14 days after release
The initiative has a shared impact goal. Individual specs contribute to it; each does not promise the entire improvement on its own.
04 / SPLIT THE SPECSSmall Specs, Small Context.
As a task grows, so does the context that people and AI agents need to understand. LoopsWork therefore aims to split work into small specs or slices that can be implemented independently.
Large specMore context · greater complexity · potentially higher AI costs
↓ Split into coherent business slices
Slice A · Load addressAPI + failure cases
Slice B · Select addressUI + acceptance examples
Slice C · Measure impactFunnel + data quality
Less context
Agents receive only the information they actually need for the task.
Better results
Small tasks can be described, implemented, and checked more precisely.
Lower costs
Focused context selection can reduce token and processing costs. Include additional agent runs and coordination in the total.
Faster feedback
Small changes can be verified earlier and move through Build and Value faster.
Small is not a goal on its own. A slice needs a clear task and independent verification. Sub-tasks help split work when they also bound the actual agent task. View in the shopping cart example.
05 / JIRA HIERARCHYA clear structure for initiatives, specs, and slices
InitiativeIntended impact
Spec · Reuse address
A bounded business change
- Slice · API integration
- Slice · Default selection
Spec · Observe the funnel
A bounded business change
- Slice · Capture events
- Slice · Verify analysis
The Initiative describes the intended impact, the Spec describes a bounded change, and the Slice is the smallest useful unit of implementation. Bugs, experiments, and tasks can remain as complementary work types.
Existing Jira types are often sufficient.
For example: a JPD idea linked to an epic, specs as stories or tasks, and slices as sub-tasks. The exact mapping depends on your Jira configuration. LoopsWork does not need a ticket type for every possibility. Jira already offers plenty of ways to create ticket sprawl.
06 / WORKFLOWAfter release: evaluate impact
- Draft
- Ready
- Building
- Review
- Released
- Measuring
- Learned
Release → evaluate impact
A change is technically complete when the agreed quality criteria are met and it has been released in a controlled way. For critical components, this includes required observability, useful alerts, and tested failure behavior. The loop is still open until the actual impact has been evaluated and feedback becomes available.
- Expected Value
- Release
- Measurement
- Actual Value
- Decision
✓ Impact confirmed↻ Keep observing△ Change required✕ Impact not confirmed
This is a logical flow, not a prescribed Jira workflow. Measuring and Learned can be represented in a linked Value Review item or in fields. Feedback can return to the spec or a new hypothesis at any time.
Feedback Debt
Feedback Debt means released changes whose impact has not yet been evaluated.
- Released Specs
- 24
- Value checked
- 17
- Feedback Debt
- 7
Growing Feedback Debt is a warning: the team is producing changes faster than it learns from them.
Illustrative data from the same cohort. Also check the age of open reviews and which are already due.Record the review owner, review date, and evidence link on each released spec. In the Value Review, prioritise overdue or high-risk feedback. Useful evidence and a documented decision close the review; a status change alone does not.
07 / CONFLUENCEConfluence keeps the context that should last
Operational work belongs in Jira. Lasting knowledge belongs in Confluence. Confluence serves as a knowledge base for both people and AI agents.
Space · LoopsWork
- Team Context
- Product Context
- Architecture
- Decisions
- Experiments
- Learnings
- AI Context
Give durable context an owner and a freshness date. Link confirmed specs and decisions instead of copying the same rules repeatedly.
08 / DECISION LOGDecisions remain easy to find
Customer Profile remains the source of truth
- Context
- Checkout needs additional customer data.
- Decision
- The Customer Profile Service remains the source of truth.
- Why
- Avoid duplicate data storage.
- Consequences
- Checkout uses the Profile API.
Specs link only the context they actually need.
09 / LEARNING LOOPResults create new context
Existing customers benefit most
- Observation
- Express Checkout mainly improves conversion for existing customers.
- Evidence
- Existing customers: +4.2% · new customers: +0.1% relative conversion change in this example
- Learning
- The main friction point for new customers is probably before payment. This is a new hypothesis, not a proven finding.
- Change
- Investigate the new hypothesis; check data comparability and uncertainty.
- Spec
- Change
- Result
- Learning
- New hypothesis
- New spec
↻ The learning becomes context for the next Build Loop.
10 / EXECUTIONWork can be assigned to people and agents
Traditional frameworks assign work to roles and people. AI-supported delivery adds another question: who executes the work—a person, an agent, or both?
Human
Max
The person implements the task themselves.
AI Agent
Copilot Backend Agent
An agent works largely independently on a clearly defined spec or slice.
Hybrid A common practical arrangement
Max + Copilot Backend Agent
The person remains accountable while the agent carries out parts of the work.
Agent names here describe illustrative execution profiles, not automatically available Jira users.
11 / ACCOUNTABILITYHumans remain accountable. Agents carry out the work.
Load the saved address
- Responsible Human
- Max
- Execution / Agent
- AI Agent / Copilot Backend
- Context
- Customer Profile API · DEC-023 · Checkout Architecture
LoopsWork separates accountability and execution. An agent can carry out the work; a person remains accountable.
Humans own decisions. Agents own tasks.Humans are accountable for decisions. Agents carry out work.
In practice, the responsible person can remain the Jira assignee. Execution Mode and Execution Agent can be fields or part of the agent task. The approvals shown are boundaries for this example task.
12 / TECHNICAL CONNECTIONJira context for coding agents
The Atlassian Remote MCP Server gives MCP-capable AI systems access to Jira and Confluence context. Relevant context no longer needs to be copied into prompts repeatedly.
Jira
Spec · status · task
Confluence
Architecture · Decisions · Learnings
Atlassian Remote MCPContext & permitted tool actions
GitHub Copilot
In an MCP-capable environment
OpenAI Codex
With a configured MCP connection
Claude Code
Or other MCP-capable agents
Codebase / development toolsSeparate agent access to the repository
Assignment and access are different things.
LoopsWork models the logical assignment to an Execution Agent. MCP then gives the agent access to the required Jira and Confluence context. MCP does not automatically make a Copilot agent a Jira assignee or start a coding task.
Configure the client, authentication, and permissions. Access follows approved rights; an agent role alone grants no permissions.
Jira MCP and Atlassian MCP provide one possible technical connection for an AI agent workflow. Follow the official documentation for setup.
13 / AGENT BOUNDARIESGood agents need three things
Context
What must the agent know?
Spec · Architecture · Decisions · APIs · Constraints
Capability
What may the agent do?
Read code · change code · create tests · create a PR · update Jira
Boundary
Where does a human decide?
Architecture decisions · merge · production release · budget · business acceptance
Give agents context, capability and boundaries.
14 / WITHIN THE TEAMAI agents in a LoopsWork team
Scout
Finds relevant context, dependencies, and existing knowledge.
Planner
Analyzes specs and proposes small slices.
Workmaster
Implements agreed changes and makes open reviews and missing evidence visible. Merge approval remains with the named human reviewer in the Delivery Team.
Reviewer
Reviews acceptance criteria, tests, risks, and implementation.
Impact Analyst
Prepares measurements and Value Reviews.
Learning Guide
Identifies patterns and suggests learning or experiments.
AI builds more than features.
As required by the spec, agents can add monitoring configuration, logs, metrics, alerts, failure-case tests, fallbacks, recovery, and runbooks. People are accountable for criticality, acceptable risk, alert thresholds, SLOs, escalation, and approval.
Humans decide. Agents support.
15 / END-TO-ENDA complete LoopsWork cycle
A LoopsWork cycle connects Build, Value, and Learning: from intended impact through implementation and measurement to learning that triggers new work. The three loops connect and can run in parallel.
An end-to-end fictional checkout example. These measurements are not actual product results.
- 01
JPD Initiative
Reduce checkout abandonment
- 02
Spec
Select the saved address by default
- 03
Planner
Split the spec into small slices
- 04
Assignment
Responsible: Max · Execution Agent: Copilot Backend
- 05
MCP Context
Retrieve focused Jira, Confluence, and decision context
- 06
Build
Agent creates the change, tests, and PR
- 07
Review
Reviewer and human review the work
- 08
Release
A human approves publication
- 09
Value Review
12.4% → 9.8% abandonment in this fictional example
- 10
Learning
Existing customers benefit most
- 11
New hypothesis / spec
Investigate obstacles for new customers
↻ New specs start with knowledge from the previous loop.
16 / AUTOMATIONThe loops keep learning and moving
Spec createdScout / Planner review spec quality
ReadyCheck relevant context and the confirmed version
BuildingExecution Agent receives a bounded task
ReleasedSchedule a Value Review
Measurement date reachedImpact Analyst prepares a summary
Value Review completedDocument learning
Relevant learningUpdate confirmed context
Jira Automation, Rovo, and other agents can support many of these transitions. These are configuration examples. External coding agents need an appropriate trigger or orchestration in addition to MCP access.
A ‘Spec Coach’ describes work done by Scout and Planner here, not a seventh AI Agent Role. Set write permissions, approvals, and budget boundaries for each task.
Automate work while keeping people accountable.
17 / RITUALSLess status. More decisions.
Existing LoopsWork rituals combine AI preparation with human clarification and decisions. Cadences are starting points; trigger rituals when needed.
Flow Check
Agents prepare impediments, open reviews, and pending acceptance. People decide the next concrete action.
View the agenda →Refinement
Scout and Planner prepare examples, open rules, and small specs. The Product Owner, team, and Feature Partner clarify the next change.
View the agenda →Spec Clinic
When rules conflict or budgets are tight, agents suggest options. People agree on the smallest useful scope.
View the agenda →Acceptance Slot
The Reviewer gathers criteria and evidence. Feature Partners confirm real scenarios or identify gaps.
View the agenda →Value Review
The Impact Analyst prepares verified measurements and user feedback. The Product Owner decides the next product work.
View the agenda →Retrospective
The Learning Guide summarizes approved observations. The team evaluates its ways of working and agrees on an experiment.
View the agenda →Learning Exchange
Agents prepare evidenced before-and-after examples. Teams share learning and check transferability.
View the agenda →18 / LOOP GUIDEThe Loop Guide focuses on the loops rather than administering Jira.
- Are specs getting larger?
- Is Feedback Debt growing?
- Are Value Reviews waiting too long?
- Are agents receiving too much context?
- Does learning actually lead to changes?
- Where do loops remain open?
The Loop Guide makes missing feedback and impediments visible. They help the team close loops and improve ways of working.
19 / BUILD. VALUE. LEARN.Jira makes the LoopsWork loops visible.
LoopsWork connects outcomes, small specs, implementation, impact, and learning into a continuous system.
Humans remain accountable.
Agents carry out work.
Feedback closes the loop.