Agentic Development Glossary: From Spec and Handoff to Verification and Ship

Friday, 4pm. The QA agent marked a ticket "Done" after running tests. The Developer agent had marked it "Done" two hours earlier after pushing code. The PM marked it "Done" in Linear when the Planner agent finished the breakdown. Three different "dones" for the same feature. Zero deployments. Nobody shipped anything. If you're running sprints with AI agents, this vocabulary mismatch will cost you.

That's when I realized we'd borrowed all this terminology from human teams and never stopped to ask if the words meant the same things anymore. Classic.

We've written glossaries for agentic DevOps and scrum in the agent era. This one covers different ground — the delivery flow. Spec to ship. The stations along the way, redefined for when agents are doing the traveling.

Twelve terms. I tried to keep it tight. (I'm bad at tight.) Some of these overlap with the other glossaries — I'll point to those where relevant. What's here is specifically about the journey a piece of work takes from idea to deployed.

1. Spec

What it meant: A written description of what to build. For humans, "use your judgment" covered the gaps.

What it means now: The input contract for an agent. Agent specs can't wave hands.

A human developer reads "add a delete button" and makes twelve unspoken decisions. Which icon? Where on the page? Confirmation dialog? They draw on context and taste. An agent reads the same spec and either guesses (confidently, wrongly) or stalls.

Good agent specs include exact acceptance criteria, test commands to validate completion, files not to touch, and what "done" looks like in testable terms. The guide to writing tickets AI agents can complete goes deeper. I still write underspecified tickets sometimes. Old habits.

2. Spec Decomposition

What it meant: Breaking a large feature into smaller tasks.

What it means now: A Planner agent's primary job.

The Planner takes a feature-level spec and outputs ticket-sized specs — each bounded, testable, assignable. Bad decomposition: "Implement auth." That's a project, not a ticket. Good decomposition: "Add password hash util (input: plaintext, output: bcrypt hash, test: verify against known hashes)."

DevOS's Planner agent handles decomposition automatically. But review the breakdown anyway — planners miss edge cases, and honestly, so do I when I'm rushing. Ten minutes reviewing decomposition saves hours fixing misaligned work. Maybe more.

3. Handoff

What it meant: When one person's work becomes another's input. Usually informal — a Slack message, a tap on the shoulder.

What it means now: Structured context transfer between agents.

Agent-to-agent handoffs can't rely on ambient knowledge. Without explicit context, information evaporates. A well-structured handoff includes what was completed (files changed), what's expected next, constraints discovered, and blockers to watch for.

Bad handoff: ticket moved to "Ready for QA" with no comment. Good handoff: "Changed auth/hash.ts and auth/hash.test.ts. Unit tests pass. Integration test needs mock server running." The difference is annoying to enforce but matters. The guide on fixing AI agent coordination shows what breaks without handoff protocols.

4. Definition of Done (DoD)

What it meant: Team-agreed criteria for when work is complete.

What it means now: The same criteria, enforced by automation rather than social norms.

Humans feel bad marking something done prematurely. Teammates notice. Agents? Zero shame. They'll mark done whenever their internal signal fires, regardless of CI status.

The fix: encode DoD in workflow automation. A ticket can't move to Done unless CI is green, review is approved, and branch is merged. DevOS enforces this through status gates. The agent can try to mark done, but the board won't let it until criteria are met.

5. Acceptance Criteria

What it meant: Conditions defining when a user story is satisfied.

What it means now: The validation contract that gates ticket completion.

For humans, acceptance criteria are guidelines. For agents, they're test cases. Vague criteria like "user should be able to delete their account" don't work. Agent-ready criteria: "Given a logged-in user on /settings, when they click 'Delete Account' and confirm, then their record is soft-deleted. Test: npm test -- --grep 'account deletion'."

The test command is the key. If the agent can run a command and see pass/fail, it can self-validate. Manual testing should be reserved for the genuinely untestable — and there's less of that than most teams admit.

6. Verification

What it meant: Confirming work matches requirements.

What it means now: Automated and human checks that confirm agent work is correct.

Agents produce code faster than humans can review. Way faster. If your only verification is human eyes, you'll drown in PRs. Build layers: unit tests, integration tests, linting, type checking, CI pipeline. DevOS's QA agent handles these automatically.

Human review focuses on judgment: is this the right approach? Security implications? You're not checking semicolons — you're checking decisions. Track verification failure patterns; repeated failures signal spec ambiguity or config issues. (I learned this the hard way after a week of blaming the agent for what was actually a flaky CI config.)

7. Review Gate

What it meant: A checkpoint where work waits for approval.

What it means now: Where human judgment intersects agent output.

Review gates catch what automation misses. Configure based on risk: low-risk (docs, tests) can auto-approve after CI. Medium-risk (feature code) needs one reviewer. High-risk (auth, payments) needs two reviewers plus explicit sign-off.

Agents should never bypass review gates. Even if you trust the output, the gate exists for when trust is misplaced. I know it's tempting to skip reviews for "obviously fine" changes. Don't. The human-in-the-loop best practices post covers gate design.

8. Rework

What it meant: When completed work gets sent back for changes.

What it means now: The cost of spec ambiguity and verification gaps.

Agent rework happens when specs are unclear, verification missed something, the agent hallucinated an API, or context was lost between handoffs. Track rework rate as a health metric. If 40% of agent tickets need rework, something upstream is broken.

Track rework by category. Spec ambiguity? Improve templates. Handoff loss? Enrich context. Hallucination? Add guardrails. And if your rework rate is zero? Suspicious. Either the agents are doing trivial work, or rework is hiding in "polish" tickets nobody counts.

9. Ship

What it meant: Deploy to production. Make it live.

What it means now: The final delivery stage, ideally automated.

Human flow: merge → manual deploy → monitor. Agent flow: merge → auto-deploy → agent-monitored observability. DevOS's DevOps agent handles the deploy step — connecting to Railway, running deployment, verifying health checks. We covered this integration in depth in our CI/CD pipeline with AI agents guide.

Ship means more than deployment: deployed successfully, health checks passing, no error spike, feature accessible. The DevOps agent watches the first three. The fourth sometimes requires a human decision — is this thing actually working for users? Make that decision point explicit.

10. Rollback Trigger

What it meant: The condition that makes you undo a deployment.

What it means now: An explicit threshold agents monitor and act on.

Rollback triggers should be numbers: "error rate exceeds 1%" or "p99 latency crosses 500ms." Don't let agents define thresholds — they might optimize for minimizing rollbacks rather than minimizing user impact. That's a weird incentive misalignment you don't want to debug at 2am.

Configure rollback scope too. Roll back this service or the whole release? Each decision should be pre-made in config. The agentic DevOps glossary covers rollback architecture.

11. Context Window

What it meant: The amount of text an LLM can consider at once.

What it means for delivery: How much project context an agent retains while working.

Delivery flows span days or weeks. An agent that finished a spec Monday might work on a related ticket Thursday. Does it remember? DevOS uses a three-tier memory system: Graphiti knowledge graphs, embedded memories, and automatic state recovery.

Without persistent context, agents add back edge cases that earlier specs explicitly excluded. Annoying. Memory is how agents stay consistent across handoffs. The designing memory systems for coding agents post covers implementations.

12. Sprint-to-Ship Ratio

What it meant: (New term) Percentage of committed work that reaches production.

What it means: A health metric for agent-assisted delivery.

Commit 10 features, ship 7 — that's 70%. The gap is stuck in review, blocked on rework, or failed verification. Track separately for human and agent work; agent ratios start lower while you calibrate specs and handoffs. Ours was ugly the first month. If you're measuring AI agent team performance, sprint-to-ship ratio belongs on your dashboard.

A sudden drop signals a delivery flow problem. Find where tickets stuck: spec decomposition? Review queues? CI flakiness? Fix the bottleneck. Usually it's something boring.

Honorable Mentions

Blast radius: How much damage a failed ship can cause. Covered in depth in the agentic DevOps glossary. For delivery flows, scope blast radius by deploying to smaller cohorts first.

Feature flag: A toggle that controls whether shipped code is active. Agents can ship code, but feature flag decisions often stay human. Define who owns the flag flip. Don't leave it ambiguous.

Dry-run deploy: Running the deploy process without actually deploying. Useful for catching config issues before they hit production. Agent deploy flows should include dry-run steps by default. For teams evaluating platforms, the AI agent platform evaluation checklist covers what to look for.

Quick Verdict

If you take one thing from this glossary: encode your definition of done in automation, not social norms. Agents don't feel embarrassed marking something done prematurely. Build the gates.

Second takeaway: handoff context matters more than you think. When information gets lost between agents, it resurfaces as rework. Invest in structured handoffs early.

The vocabulary will keep shifting — mid-2026 is still early for this stuff. But if your team is running agents in the delivery flow, these twelve terms will help you talk about what's happening. Talking clearly is half the battle. Maybe more than half. (For context on how VDL runs nine products with an AI workforce, see how we manage 9 SaaS products.)

Frequently Asked Questions

What makes a good spec for an AI agent?

A good agent spec is explicit about acceptance criteria, inputs, outputs, and constraints. Unlike human specs that can say "use your judgment," agent specs need concrete boundaries. Include test commands to run, files to avoid modifying, and what "done" looks like. The more ambiguous the spec, the more confidently wrong the agent's interpretation will be.

How do handoffs work between AI agents?

Agent-to-agent handoffs pass structured context — what was done, what's expected next, which files changed, and any blockers discovered. A Planner agent hands to a Developer agent with a spec plus constraints. Developer hands to QA with changed files plus test expectations. Without explicit handoff context, agents lose information and make conflicting assumptions.

What does verification mean for AI agent work?

Verification means automated checks that confirm agent work matches the spec. Unit tests, integration tests, linting, type checks, CI pipeline — all forms of verification. Human review is verification too, but it doesn't scale. The more you can encode into automated verification, the faster agents can ship without creating rework.

When is an agent ticket ready to ship?

An agent ticket is ship-ready when: code compiles, tests pass, CI is green, review is approved, and the work matches the original spec's acceptance criteria. "Agent finished writing code" is not ship-ready. Neither is "PR opened." Ship-ready means deployable to production without further work — same standard as human tickets, enforced more strictly.

---

Join the DevOS Waitlist

AI agents that work as employees inside your sprints, standups, and tickets — not single-task copilots. Planner / Developer / QA / DevOps agents pick up work from the backlog, ship in branches, request review. Linear-shaped backlog UI with AI underneath. Pre-launch.

Join the waitlist → · How agents-as-employees works