Skip to content

Solution Design Playbook

Blueprint checklist

Blueprint checklist

Use this checklist to decide whether a design is ready to build, and later whether it's ready to launch. It supports the Scope, QA and Launch phases of Your First Agent. If a value is still unknown, write "unknown" and name who will answer it. Hidden gaps cause more trouble than visible ones.

The blueprint

A blueprint is ready for review when it answers each of these:

  • Outcome. What the solution achieves, and the measure of success.
  • Audience and interface. Who uses it, and where.
  • Trigger and timing. What starts the work, and whether it happens during or after a conversation.
  • Agents. Each agent's name, purpose, model and reason for that model, and what its instructions cover.
  • Data. The source of truth for each kind of data: knowledge, a table, or live access.
  • Connectors. Each one marked as import, agent access, or both.
  • Tools. Exactly which tools each agent needs, and which of them can change data.
  • Workflow. For any Loop: the steps, branches, approvals and expected results.
  • Safeguards. Identity, privacy, sensitive data, retention and escalation.
  • Results. What people see after success, partial success and failure.
  • Open items. Assumptions, permissions still needed, outside dependencies, and the tests that will prove it works.
If part of the solution is outside raia, such as a custom upload screen, a mail provider's delivery events or a new API endpoint, list it as an external dependency with an owner. Don't let it hide inside an agent or a Loop.

Before you build

  • The design is no bigger than it needs to be. Every agent and Loop step has a reason.
  • Public and private audiences are separated where information is private.
  • Every system and sign-in is named, rather than assumed to be connected.
  • Business rules, such as priority, scoring and routing, come from the business, with examples.
  • Field values and record types have been checked against the real system.
  • Every write action has an approval rule.
  • Every failure has a defined next step.

Before you launch

  • Realistic everyday questions are answered correctly, from the right sources.
  • Edge cases and unknown questions are handled honestly, without invented answers.
  • Attempts to reach information or actions the user shouldn't have are refused, and you've checked the agent's knowledge and tools, not only its replies.
  • Tool results show that actions really happened.
  • Escalation reaches a person, and notifications arrive.
  • Test agents and saved test scenarios are kept for retesting.
  • A named person has reviewed the results and accepted them.

Rolling out safely

  1. Start with narrowly scoped tools and a person approving actions.
  2. Review the action history and conversations regularly.
  3. Automate further only for low-risk cases where the results justify it.
  4. Retest whenever instructions, knowledge, models, tool access or Loop branches change.