How to Write a Verifiable AI Agent Goal

Write a Goal an Autonomous Agent Can Verify

A durable autonomous-agent goal has five core sections: Outcome, Context, Constraints, Verification, and Complete.

Outcome names the state you want. Context gives the agent the source of truth and operating background. Constraints define the boundaries the result must respect. Verification names the evidence that proves the work. Complete states when the agent should stop and what must still be handed to a human.

This is a practical operating format, not a universal standard issued by Google or OpenAI.

flowchart TD
    A["Outcome: desired state"] --> B["Context: source of truth"]
    B --> C["Constraints: boundaries and authority"]
    C --> D["Verification: observable evidence"]
    D --> E["Complete: stopping and handoff condition"]
    E --> F{"Evidence passes and no authorized work remains?"}
    F -- "No" --> G["Iterate or report a real blocker"]
    G --> D
    F -- "Yes" --> H["Stop and hand off"]

Outcome describes the state, not the activity

“Work on the website” is an activity. “The public episode page renders the approved article, transcript, show notes, and source links on desktop and mobile” is a state.

The outcome should let another person picture the finished result without prescribing every implementation step. It can name required artifacts, users, systems, and quality.

Avoid vague success words such as improve, optimize, modernize, or make better unless the goal defines what changes and how it will be observed.

An autonomous agent can generate endless activity around a vague verb. A state gives the work somewhere to arrive.

Context identifies authority and history

Context tells the agent which repository, vault, document, database, ticket, transcript, design, policy, or user decision controls the work.

It also identifies the current state and why the outcome matters. This prevents the agent from solving an older version of the problem or choosing a plausible source that is not authoritative.

Google's current Antigravity projects documentation allows projects to span multiple folders with scoped settings and permissions. That flexibility makes source authority more important. Two folders can contain conflicting versions of the same fact.

State which one wins. Preserve source material rather than silently normalizing it.

Context is not a request to paste everything available. Give the agent the evidence needed to act and the route to inspect more.

Constraints define quality and authority

Constraints include technical, editorial, legal, security, privacy, cost, time, format, compatibility, and interaction boundaries.

They also define actions the goal does not authorize.

A goal to prepare public content may allow local Markdown edits and web research while withholding publication, outreach, analytics changes, and external messages. A goal to diagnose a deployment may allow logs and read-only inspection without authorizing a production change.

Google's permissions documentation distinguishes Deny, Ask, and Allow rules. The goal should align with the configured authority instead of assuming the agent can or should use every available action.

Constraints work best when they are testable. “Keep it human” becomes more useful when paired with examples such as natural Markdown, no em dashes, no public-prose bullet stacks, no repetitive bold-label-colon pattern, no unsupported hype, and no invented quotations.

Verification is written before execution

Verification answers what evidence will convince you that the outcome exists.

For software, that may include tests, a build, static analysis, security checks, screenshots, direct browser behavior, data reconciliation, and a diff review.

For content, it may include source links, word and readability checks, exact metadata, internal-link resolution, no prohibited patterns, factual review, and a visible disclosure.

For a migration, it may include source and destination counts, hashes, residuals, exception records, and a rollback path.

The NIST Secure Software Development Framework organizes secure development around preparing, protecting, producing, and responding. It does not prescribe this goal format, but it reinforces the broader point that producing an artifact is only one part of a trustworthy lifecycle.

Write the verification before the agent begins so the test is not weakened to match whatever the agent happened to produce.

Complete is a stopping rule

Complete should be stricter than “the agent says it is done.”

The expected artifacts exist. Required checks pass. Known exceptions are recorded. Source material remains preserved. No required authorized work remains. Consequential actions outside the goal remain clearly unperformed.

A maximum iteration count is a containment measure, not a completion condition.

If the agent reaches the limit without evidence, it should stop safely and report what remains. It should not label incomplete work as complete because the budget expired.

Name the blocked condition

A strong goal explains what the agent should do when it cannot proceed.

The agent should exhaust safe in-scope checks, preserve completed work, identify the exact missing input or authority, and ask for the smallest decision that changes the state.

It should not invent the answer. It should not expand the task silently. It should not repeat the same failed check forever.

The blocked report should distinguish missing information, missing access, external failure, conflicting authority, and a decision the user must make.

That distinction helps the user resolve the real problem.

Separate preparation from release

Many goals produce an artifact that someone else must approve.

A publication package can be complete as a review-ready artifact while publication remains unauthorized. A migration plan can be complete without executing the cutover. An email draft can be complete without sending it.

This is not incomplete work when the outcome explicitly stops at preparation.

It becomes misleading only when the goal promises a live result and the agent quietly substitutes a plan.

The completion section should name the handoff and the authority required for the next action.

Give subagents smaller goals

Subagents need the same structure at a smaller scale.

Google's subagent documentation describes separate context, workspace choices, monitoring, and inherited safety configuration. A subagent should receive one bounded artifact or question, the relevant source, local constraints, a validation requirement, and a return format.

Do not send the entire parent goal to every subagent unless they genuinely own the entire outcome. That duplicates context, increases overlap, and makes reconciliation harder.

The parent remains responsible for combining the evidence and deciding whether the overall goal is complete.

Use hooks to reinforce, not replace, the goal

Google's hooks documentation supports scripts before and after tools, around model calls, and at stopping conditions.

A hook can run a linter, block a dangerous command, capture diagnostics, or force a final check. It is useful because it makes part of the verification executable.

The hook cannot rescue an ambiguous outcome. It also needs review as executable code with access to local context.

Use hooks to enforce a known rule, not to hide the rule from the goal.

An example in natural language

Suppose the outcome is a public-ready episode package.

The context names the canonical audio, raw transcript, current episode folder, editorial standards, public site, and the episode's place in the corpus.

The constraints preserve the raw transcript, require current primary sources, protect private detail, prohibit invented facts and synthetic formatting, limit external changes, and keep publication unauthorized.

The verification requires distinct reader jobs, complete page plans, working external and internal links, readable Markdown, original visuals, factual and specialist review gates, and zero validator errors.

Complete means every planned draft and research record exists, checks pass, the release handoff is explicit, and the agent stops before publication.

That goal can run because the destination and evidence are clear.

The goal is a contract with reality

A prompt tells the agent what to say next. A goal defines a state the agent can work toward across many actions.

The format matters because autonomy stretches the distance between instruction and result. Outcome, Context, Constraints, Verification, and Complete keep that distance inspectable.

E115 warns against confusing visible output with progress. E120 describes the rise of the AI coworker. E118 supplies the bridge between them: a coworker becomes useful when the work has a shared definition of done.

Editorial and authority note

This guide presents a practical operating format derived from E118 and the Venture Step workflow. It is not claimed as a universal Google, OpenAI, legal, security, compliance, project-management, or contracting standard. Technical, security, legal, editorial, accessibility, and founder review remain required before publication.

AI assisted with research, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority.