Most protocol diagrams put  Model Context Protocol (MCP), Agent2Agent (A2A) protocol, and Agent Communication Protocol (ACP) in three equal columns. I think that framing causes half the confusion. They aren't three interchangeable ways for agents to chat.

MCP solves a capability-access problem. A2A solves a delegation problem. ACP explored a REST-first version of agent communication. Once those boundaries are separated, the architecture becomes much easier to reason about.

Have you ever delivered a feature that passed testing, matched the original ticket, and still wasn’t what stakeholders expected?

Most developers have experienced some version of this. The implementation works, the requirements appear satisfied, yet the result doesn’t fully match the original intent.

In the era of AI coding assistants and autonomous development agents, this challenge matters even more. AI can accelerate implementation dramatically, but it can only work with the context it receives. When requirements are incomplete, scattered, or ambiguous, AI tools may confidently generate code that solves the wrong problem.

The problem often starts before you write code.

More often, the issue starts earlier, when requirements are discussed, interpreted, and passed between stakeholders, developers, and teams. As projects grow, important details become scattered across meetings, documents, tickets, and chat conversations. Small gaps in understanding can eventually lead to unmet expectations, delayed releases, and unnecessary rework.

This challenge has made Spec-Driven Development (SDD) increasingly important for teams adopting AI-assisted development. As organizations integrate AI into planning, coding, testing, and review processes, specification quality often determines the quality of the AI-generated outcome.

Rather than relying on assumptions and fragmented project knowledge, SDD creates a structured source of truth that both humans and AI systems can use to understand requirements, constraints, acceptance criteria, and business intent before implementation begins.

To help teams adopt this approach, we’ve published the Spec-Driven Development Handbook, a practical guide for moving from ideas and requirements to implementation and validation through clear specifications and technical planning. It helps teams reduce rework, improve alignment, and build with greater confidence.

In this blog, we’ll explore the fundamentals of SDD, why it matters, and how Syncfusion^® Code Studio helps teams put these principles into practice.

AI makes clarity more valuable, not less

AI coding agents have changed how software is built. Tasks that once took days can now be completed in minutes through AI-generated code, tests, documentation, and implementation plans.

However, AI introduces a new reality: development speed is no longer the primary bottleneck. Requirements clarity is.

An AI agent can generate hundreds of lines of code in seconds. But if business rules, edge cases, or acceptance criteria are unclear, the result may still require significant revision. In practice, many teams discover that AI doesn’t eliminate the need for planning. Instead, it increases the value of high-quality specifications.

The better the specification, the more accurately AI can:

• Generate implementation plans.
• Create production-ready code.
• Identify requirement gaps and inconsistencies.
• Produce meaningful test coverage.
• Validate outcomes against business expectations.

In this environment, specifications become more than documentation. They become the operational context that powers effective AI-assisted development.

Why good features still miss the mark

When projects run into trouble, the root cause is often ambiguity rather than technical complexity.

Requirements rarely live in a single place. Discussions happen in meetings, decisions are made in chat threads, and critical details may never make it into documentation. As information becomes fragmented, different team members often develop different interpretations of the same feature.

The result is familiar:

• Requirements remain partially defined until development is already underway.
• Edge cases surface late, often during testing or review.
• Technical decisions are made reactively instead of deliberately.
• Completed work requires revision because expectations were never fully aligned.

The larger the initiative, the more expensive these misunderstandings become.

Spec-Driven Development addresses these issues by helping teams establish a shared understanding before implementation begins.

Start with understanding, not assumptions

At its core, Spec-Driven Development encourages teams to spend more time defining the problem before building the solution.

While implementation may vary between organizations and methodologies, many spec-driven teams follow a processing sequence similar to:

Idea → Proposal → Specification → Technical Plan → Tasks → Build → Review → Validate → Release

The important principle isn’t the exact sequence. It’s ensuring that requirements, constraints, acceptance criteria, and implementation decisions are clearly defined before development begins.

Three artifacts commonly help structure this process:

• Specifications capture requirements, expected behavior, constraints, edge cases, and acceptance criteria.
• Technical plans document implementation strategies, architecture decisions, dependencies, and trade-offs.
• Tasks break larger initiatives into manageable units that can be implemented, reviewed, and validated incrementally.

Together, these artifacts create a consistent source of project context that remains useful throughout development.

Catch problems earlier

One of the biggest advantages of SDD is simple: it encourages teams to answer important questions before writing code.

Questions such as:

• What problem are we solving?
• How will success be measured?
• What is intentionally out of scope?
• What constraints must be considered?
• How will the solution be validated?

Answering these questions upfront often prevents confusion later.

A requirement gap discovered during planning is typically easier and less expensive to address than one discovered after implementation. Once code has been written, tested, reviewed, and integrated, resolving the same issue often requires significantly more coordination and rework.

Why SDD matters even more with AI coding agents

AI coding agents can generate implementations, tests, and documentation significantly faster than traditional processes. However, they face the same challenge humans do: unclear requirements produce unclear results.

Without a well-defined specification, an AI agent may have to infer:

• Business rules,
• Expected behavior,
• Edge cases,
• Validation requirements, and
• Out-of-scope functionality.

Those assumptions can lead to implementations that work technically but don’t align with stakeholder intent.

A structured specification provides the context AI agents need to:

• Generate implementation plans.
• Identify missing requirements early.
• Produce more accurate code changes.
• Create tests that reflect expected behavior.
• Validate outcomes against acceptance criteria.

In this sense, Spec-Driven Development doesn’t just help humans collaborate more effectively. It also helps AI tools operate with greater reliability and predictability.

Putting Spec-Driven Development into practice

Understanding the methodology is one thing. Applying it consistently is another.

As projects evolve, requirements change, new contributors join the team, and implementation details become more complex. Maintaining alignment across all these moving parts can be challenging.

In Syncfusion Code Studio, teams can start with a high-level feature request and collaborate with AI to progressively transform it into a structured implementation package. Instead of moving directly from an idea to generated code, teams first establish the context AI needs to produce reliable results.

This approach helps ensure AI-generated plans, tasks, code, and validation steps remain aligned with business objectives and stakeholder expectations.

For example, a proposal for “subscription management” can be expanded into:

• A specification that defines goals, requirements, constraints, edge cases, and acceptance criteria.
• A technical design that documents architecture decisions, dependencies, APIs, and implementation considerations.
• A task breakdown that converts the work into reviewable implementation units.

Teams can review these artifacts, refine requirements, identify gaps, and align on technical direction before code changes begin. This creates a stronger connection between planning, implementation, and validation throughout the development process.

This helps reduce communication gaps while providing a clearer path from concept to delivery.

A common SaaS feature that gets more complex than expected

Imagine your team is building subscription management for a SaaS application. The requirement sounds straightforward: allow users to upgrade and downgrade subscription plans. 

Before implementation begins, a spec-driven team might create a specification like the following:

Notice that most of the important implementation questions are answered before development begins. Developers, reviewers, QA engineers, stakeholders, and AI coding tools can all work from the same source of truth.

The result isn’t simply a cleaner implementation. It means fewer surprises throughout the project lifecycle and a greater likelihood that the delivered feature matches stakeholder expectations.

What you’ll learn throughout the Spec-Driven Development Handbook

The Spec-Driven Development Handbook takes these ideas further, showing how teams can move from an initial idea to a validated implementation through specifications, planning, and tasks.

Inside the handbook, you’ll learn how to:

• Define problems clearly before proposing solutions.
• Write specifications that are easier to review and validate.
• Create technical plans that identify risks and trade-offs early.
• Break complex initiatives into implementation-ready tasks.

The handbook includes practical examples, templates, and walkthroughs showing how specifications, plans, and tasks can be created and refined throughout a project’s lifecycle.

Whether you’re building a new application, modernizing existing systems, or improving collaboration across teams, these practices can help create a more predictable development process.

Who will benefit most?

The handbook is particularly useful for:

• Developers and tech leads who want stronger alignment between requirements and implementation.
• Teams adopting AI-assisted development and looking for more reliable outcomes.
• Engineers working in large codebases, where hidden dependencies and undocumented knowledge pose risks.
• Organizations standardizing development practices to improve consistency across planning, delivery, and collaboration.

Better context leads to better AI-driven software

As AI becomes an increasingly important part of the software development lifecycle, the quality of the inputs provided to AI systems becomes just as important as the quality of the code they generate.

Spec-Driven Development helps teams create the structured context that both humans and AI agents need to succeed. By making requirements, constraints, acceptance criteria, and implementation intent explicit from the beginning, organizations can reduce ambiguity, improve AI-generated outcomes, and deliver software with greater confidence.

Whether you’re experimenting with AI coding assistants or building an AI-first engineering workflow, effective specifications provide the foundation for reliable results.

The Spec-Driven Development Handbook explores these practices in depth and shows how Syncfusion Code Studio helps teams move from ideas to AI-assisted implementation through clear specifications, technical planning, and structured execution.

For questions or feedback, connect with us through our support forums, support portal, or feedback portal. We’re always happy to help, and we invite you to continue the conversation with us.

Part 8 of 8: Durable AI for InterlinedList

Back in Part 1, I said the whole series was one argument dressed up as eight posts. LLM tokens are the expensive thing, Temporal is not, and Temporal’s mechanics structurally push the token bill down. I also said the way I’d build it was to brainstorm against the real code first, then hand the agent structure instead of hope. This is where those two threads tie together.

The capstone I keep circling back to is the one that sounds the most like science fiction and is actually the most dangerous to ship carelessly: “research topic X from my saved links and draft a document with citations.” The agent retrieves. It reasons. It drafts. And if I’m not careful, it also burns through a month of my inference budget in one runaway loop while I’m asleep.

So this post is two things. The agent itself, and the playbook for building everything that came before it. The agent is the thing you build last, and the order it sits on top of is the part I actually want to argue for.

The Capstone Is Just the Earlier Pieces, Composed

This part should feel earned by now. The agentic-research-to-draft phase, the last of the proposals, doesn’t invent anything. It composes.

The link content from Part 5 (the crawl-and-cache that turns your saved URLs into readable text) is the agent’s source material. The retrieval from Part 5’s second half, the pgvector search over your own docs, lists, and messages, is how the agent finds the relevant three paragraphs instead of stuffing forty links into context. And the durable generation from Part 3, the workflow that survives a timeout and asks before it writes, is the drafting step.

Compose those three and you get an agent loop: retrieve, reason, retrieve again, draft, cite. Each of those steps is already an activity I’d have built and tested for its own feature. The agent is a workflow that calls them in a loop the model steers.

Which is exactly where it gets scary. A loop the model steers has no natural stopping point. It’ll keep deciding it needs one more search, one more fetch, one more pass at the draft. That’s not a bug in the model. That’s what an agent is. The bug would be letting it run unsupervised.

Temporal Supervising an LLM Agent Is a Nice Recursion

I like this framing because it’s a little bit funny. Temporal is an orchestrator whose entire job is supervising unreliable, long-running, retry-heavy work. An LLM agent is unreliable, long-running, retry-heavy work. So the agent runs inside a Temporal workflow, and the workflow is the adult in the room.

Three guardrails, all first-class workflow logic, none of them prompt-hope:

A hard token budget. Before every model call, the workflow calls assertBudget, the same primitive from Part 7 that reads the AiGeneration ledger and throws a non-retryable BudgetExceeded when the user’s daily or monthly ceiling is hit. The agent can want another search all it likes. If the budget’s gone, the call never fires.

A max-step cap. The loop counts its own iterations. Twelve steps, or whatever I tune it to, and it’s done. It drafts with what it has rather than spiraling.

A wall-clock timeout. Temporal’s workflow timeout means even a wedged agent eventually stops, cleanly, with whatever it produced so far.

And here’s the piece that makes the whole thing cost-sane instead of terrifying: every step is memoized. If the agent fails at step 9 of a 12-step loop (provider hiccup, worker restart, whatever) the workflow resumes at step 9. It does not re-run steps 1 through 8. It does not re-pay for the eight model calls it already made. In a serverless handler, a mid-loop failure means starting the whole expensive agent over. Here it means retrying one step.

Sketching the loop, this is the shape I’d hand Claude to fill in:

// Proposed: the supervised agent loop as a Temporal workflow.
export async function researchAgentWorkflow(input: ResearchInput): Promise<Draft> {
  const MAX_STEPS = 12;
  const context: Snippet[] = [];

  for (let step = 0; step < MAX_STEPS; step++) {
    // Governor first: a hard ceiling the agent cannot talk past.
    await assertBudget(input.userId);

    // Cheap model plans the next move over the small retrieved context.
    const move = await planNextStep({
      model: "claude-haiku-4-5",
      goal: input.topic,
      context,
    });

    if (move.type === "done") break;

    // Retrieval is mechanical and nearly free. No expensive tier here.
    const hits = await retrieveFromLinks(input.userId, move.query);
    context.push(...hits); // stays small: top-k snippets, not whole pages
  }

  // Expensive tier runs exactly once, on the final synthesis.
  return await draftWithCitations({
    model: "claude-opus-4-8",
    topic: input.topic,
    context,
  });
}

The cost story lives in the model choices, not the prose. Retrieval and planning run on a cheap tier: Haiku for the “what should I look for next” decisions, which are frequent and small. Opus 4.8, the expensive tier, runs once, on the final synthesis, over a retrieval-augmented context that stayed deliberately small the whole way through. I’m not paying Opus prices to decide which link to read next. I pay them for the draft, and that’s the one thing in the loop I think is worth it.

No clever prompt is doing that. The structure is.

How I’d Sequence the Whole Build

If you’ve read the series straight through, you might be tempted to build the shiniest thing first. Don’t. The agent ships last, and the ordering underneath it is the real deliverable of this post, because every step ships value on its own and nothing is a big-bang.

Here’s the order I’d hand myself:

1. The foundation phase: the Temporal worker and the cost primitives. The worker, the client wiring, the llmCall activity with the model cascade, assertBudget, the response cache. This is the groundwork everything else stands on, and nothing works without it. Mostly infra, not code, and it’s a week.

2. The durable publish and idempotency fix, pure win, no LLM. This is the one from Part 4: the every-minute cron that can double-publish because a partial failure re-runs on the next tick. Rebuild it as a Temporal Schedule with the message id as the workflow id, so a given message can never be published twice. Zero model tokens. It fixes a current production hazard. If I could only ship one thing from this whole series, it’d be this.

3. Durable Generate plus confirm. Part 3. Long docs stop blowing the function budget, and a wrong list schema never gets silently written because the workflow pauses on a signal and waits for a human. This is the in-product generate button, on solid footing.

4. Link crawl, then retrieval. Part 5. Crawl the links into a cache (the cheapest, highest-cache-value piece in the set) then layer pgvector retrieval on top. This is “where did I save that article?”

5. Batch enrichment, then prompt-to-list. Part 6. The fan-out that tags everything and expands anything without re-billing completed calls, then the “build a list from a sentence” flow composed on top of it.

6. The AI calendar and digests. Part 4’s second half. Now that publishing is durable, the calendar planner and the scheduled digests have solid ground to schedule onto.

7. The cost dashboard, then the agent. Part 7’s dashboard makes “cheap” visible: tokens, cache-hit rate, budget remaining. I want that governor on-screen before I ship the most token-hungry feature in the whole set. Then, and only then, the agentic capstone.

The rule underneath the whole ordering is that value ships at every step. The publish fix helps users who never touch AI. The link cache is useful before any retrieval sits on it. The dashboard is useful before the agent exists. I’m never in a state where I’ve spent three weeks and have nothing a user can hold.

The Verification Is Where the Trust Actually Lives

The meta-point of the whole series is this one, so I’ll say it flat. You do not trust an autonomous agent because the prompt was good. You trust it because it runs inside guardrails, and because tests prove the properties you care about are there.

So the verification for the agentic capstone, and everything under it, is not an afterthought. It’s the thing that makes any of this shippable:

Vitest unit tests for the activity logic and the cost math. Does the cascade pick the cheap model for planning? Does assertBudget throw at the right ledger sum? Pure functions, no DB, fast.

Temporal replay tests that prove a workflow resumes correctly after a simulated worker crash. This is how I prove, not hope, that a retry doesn’t restart the expensive agent from step zero.

An idempotency test that starts two publish workflows with the same message id and asserts exactly one publish. That’s the double-post race, closed and locked.

Cost-assertion tests, the ones I care about most for the agent. Fail an activity mid-pipeline and assert the already-completed model calls are not re-invoked on retry. Memoization is money, and this test is how I know the money’s saved.

Playwright E2E for the generate to confirm to write flow, so the human-in-the-loop gate works in a real browser and not just in my head.

A security pass before any PR: SSRF on the crawler (everything through safeFetch), IDOR on every workflow write (where: { id, userId }), prompt-injection defaults (artifacts private by default so a poisoned link can’t publish on your behalf), and budget-bypass attempts.

And every schema change (the LinkContent table, the pgvector column, the response cache) goes through the strict additive migration workflow. Hand-written, idempotent, applied to both databases. No prisma db push, no shortcuts. That workflow has broken production before, precisely when someone skipped it.

What I Actually Learned Working With Claude

The lesson closes the loop the series opened. Supervise the agent with structure, let the tests carry the trust, and it turns out that’s also how I’ve been building with Claude the whole time.

You don’t hand an agent a vague goal and hope. You hand it constraints: a budget it can’t exceed, a step count it can’t blow past, a timeout it can’t outlast. Then you make it write the tests that prove those constraints hold, the replay test, the idempotency test, the cost-assertion test. What makes the agent trustworthy is the wall around it, not how nicely I phrased the ask.

And that’s true one level up too, which I didn’t expect going in. Sequencing the build so each step is independently verifiable (the publish fix before the calendar, the cache before retrieval, the dashboard before the agent) is the same move as capping the agent’s steps. Give the work boundaries, make the boundaries checkable, prove them before moving on. Whether the thing on the leash is a research agent or my own plan to build one, the leash is what I trust.

I’ve been brainstorming this out loud for eight posts. The pieces are grounded in code that already exists: the safeFetch guards, the DSL, the crosspost fan-out, the cron that really does risk a double-post. None of it is shipped. All of it is buildable, in the order above, with value at every step. So I’m going to start at step one and build the durable publish fix, because it’s a pure win with no model tokens and it closes a real hazard. I’d love for you to follow along, as I am going to move forward now and implement this. If you’re interested, subscribe!

Adron brainstorming and working on InterlinedList.

Build a type-safe C# pipeline from scratch with generic stage contracts, heterogeneous transitions, immutable messages, and compiler-checked composition.

If your .NET pods are each using 1–2 GB of RAM, you may be leaving a lot of pod density — and money — on the table. Here are the first things I would look at.

1. Set Realistic Kubernetes Memory Limits

Do not let every pod believe it has access to the whole node.

1
2
3
4
5
6
7

resources:
  requests:
    memory: "512Mi"
    cpu: "100m"
  limits:
    memory: "768Mi"
    cpu: "1000m"

This gives the .NET runtime better boundaries and helps Kubernetes schedule pods more predictably. The .NET GC specifically looks at the container’s memory limit (not the request) to decide how much heap it’s allowed to use, so an unset or overly generous limit is what lets the managed heap grow far larger than you intended.