Build Status: Released v0.1.0

Agent Designer

Specify an agent completely enough to build it, including its tools, limits, and escalation paths.

Runs in your browser. Nothing you enter is sent to a server, and nothing is stored unless you save it to this device.

Note

What this tool does not do

This is a specification and a linter for that specification. It does not call a model and does not execute a tool call. Wherever this page says simulate, it means a deterministic expansion of the steps you authored, exactly as you wrote them. It is not a prediction of what a real model or a real tool call would do.

A short working title, used in the exported specification.

Architecture

Role, instructions, tools, memory, triggers, and exit conditions. Everything the agent is, before it ever runs.

Purpose

What the agent is for, what it must never do, what done looks like, and how success is measured.

State the outcome, not the mechanism.

A hard boundary, stated as a rule an engineer could check the build against.

What exists, or what changed, at the end of one successful run.

A measure that holds across many runs, not just one.

Memory and triggers

What the agent remembers, and what starts a run. Both are named directly in the PRD as first class parts of the architecture, not incidental detail.

What persists between steps, between runs, or not at all, and for how long.

An event, a schedule, an incoming message, or a manual call.

Tools

Every tool the agent can call. Name each one plainly, state what it needs and what it returns, and mark whether it mutates anything, whether that mutation can be undone, and whether it needs a human to confirm it first.

Autonomy

The level this agent runs at, checked against the tool list above. A mutating, irreversible tool combined with full autonomy is a contradiction, and it is flagged loudly rather than accepted quietly.

Why this level, not a stricter or looser one.

Handoffs

When this agent escalates to a human or to another agent, what context moves with the handoff, and who owns the task afterward. An escalation path with no owner is where work gets dropped silently, so it is flagged.

Limits

The budget this agent runs inside, and the conditions that stop it. An agent with no stop condition can keep running indefinitely once started.

Maximum tool calls in one run.

Maximum wall clock minutes in one run.

For example, "$0.50 per ticket".

What happens when a tool call fails once, and how many times it is retried.

One condition per line. At least one is required.

Failure

What the agent does when a tool call fails, when it is uncertain rather than wrong, and when it detects it has looped. An agent with no defined uncertain behavior is incomplete.

Uncertain is not the same as wrong. State what it does when it does not know.

Mission

Step through one sample task as a deterministic walkthrough of the agent above. Every step is typed as an observation, a decision, an action, a result, or a memory update, so the five stay distinct rather than collapsing into one generic log line. Every action must name a tool from Architecture, or it counts as unauthorized. Steps that repeat belong to a loop, and a loop needs both a limit and an exit condition below.

The one task this walkthrough steps through.

Loops

A labeled block of steps that repeats. Every loop used below needs a maximum iteration count and a stated exit condition; the limit is a backstop, not a substitute for the condition.

Steps

The walkthrough itself, in order. An action step with no matching tool is flagged as unauthorized below.

Team

Delegation and handoffs. Solo is the default and a complete answer on its own: a single agent works before team mode is ever introduced. Open this only once the mission actually involves another agent.

Team roster

Who else is on the team. The Handoffs panel in Architecture already carries what moves and who owns it after a handoff; this roster names who they are.

Observatory

The mission above, expanded into an ordered timeline. Not a model call and not a benchmark: a mechanical walkthrough of what you authored, including where a loop halted at its limit and where an action had no matching permission.

Simulated run

Every entry keeps the type it was authored with. A loop with a stated limit runs to exactly that many iterations, then stops.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Specification status

Completeness is every required field filled in. Ready to build also requires zero unresolved critical flags, so a full form with a contradiction still is not ready.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Risk flags

Contradictions the tool can check for automatically, across every mode. Silence here means these specific checks found nothing, not that the design is safe.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Full specification

Everything above, in one document. Copyable, and identical to the markdown export below.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.
  
Export
Note Why does the autonomy level have to match the tool list?

An autonomy level is a promise about who is watching. Suggest only promises nothing acts without a human choosing to. Act with confirmation promises a checkpoint before anything mutating happens. Fully autonomous promises the opposite: no checkpoint at all, ever.

A tool list is a set of facts about what the agent can actually do. When a fact contradicts a promise, for example an irreversible delete sitting inside a fully autonomous agent, one of them is wrong. The tool cannot know which one you meant, so it flags the contradiction instead of quietly picking a side.

Note Why does an action need a matching permission?

A mission step that says "deletes the file" reads like an authorized action right up until you check whether a tool called exactly that exists. A typo in a tool reference, or a tool the walkthrough assumes but Architecture never defined, produces a step that looks fine in prose and does nothing real underneath it.

Requiring every action to resolve to a real tool from Architecture is what makes the mission trustworthy as a walkthrough of the agent above it, rather than a separate story that happens to sit next to it.