How to Write a Goal for an AI Agent That It Cannot Game

How to Write a Goal for an AI Agent That It Cannot Easily Game

An AI agent goal needs more than an outcome and context. A useful operating goal has seven parts: outcome, context, constraints, authority, verification, stop conditions, and reporting. Together, they define what must become true, what the agent may use, which paths are unacceptable, what it may change, how completion will be tested, when it must stop, and what the operator needs to review.

No format can guarantee that an agent will behave correctly. The purpose is to make wrong work visible before recurring access turns one bad assumption into a system.

The result

At the end of this process, you should have one page of ordinary language that another person can review before the agent starts.

The document should be specific enough that a reviewer can answer four questions. Did the agent reach the intended state? Did it stay inside its information and action boundaries? Is there evidence for the result? Did it stop and report when it could not proceed safely?

If the only evidence of completion is the agent saying it completed the task, the goal is not finished.

flowchart LR
    A["1. Outcome"] --> B["2. Context"]
    B --> C["3. Constraints"]
    C --> D["4. Authority"]
    D --> E["5. Verification"]
    E --> F["6. Stop conditions"]
    F --> G["7. Reporting"]

The seven-part goal format is Venture Step’s operating model. The verification principle is informed by the broader testing and evaluation resources in the NIST AI Resource Center.

Before you begin

Choose one responsibility with reversible actions and a source you can inspect. Research, classification, draft preparation, document inventory, or queue maintenance are better first tests than publishing, sending, purchasing, deleting, or making commitments.

Do not begin with the instruction you plan to type into the product. Begin with the state you need to exist after the work. This prevents the tool's interface from deciding the job for you.

In E120, Dalton asked Gemini Spark to help manage a podcast guest pipeline. Spark moved quickly and produced a useful working sheet, but it did not ask enough questions before beginning. The experience showed that low setup friction does not remove workflow design. It moves the design into the goal and the feedback loop.

1. Define the outcome as a finish state

Describe what must be true when the work is finished. Avoid verbs that name activity without establishing a result.

"Research podcast guests" permits an endless stream of names. "Produce ten review-ready guest candidates, each supported by public sources and a distinct fit rationale, with no outreach sent" has a count, a quality threshold, an evidence requirement, and an authority limit.

The outcome should be observable in a place the operator controls. That may be a table, a set of files, a draft, a report, or a changed application state. Name the destination.

Avoid a single success metric when it can be satisfied without the intended result. An agent told to maximize a score may optimize the score. It does not share the unstated reason the score exists.

Dalton uses a Tetris example in E120. If the goal is "get the highest score," a system might find a loophole that produces points without playing the game as intended. A stronger goal defines the valid environment, allowed actions, evidence, and stopping rule along with the score.

2. Bound the context

List the authoritative sources the agent needs and the sources it may search. State which systems are out of scope.

Context includes more than documents. It includes definitions, prior decisions, examples, the intended audience, time boundaries, and the current system of record.

For a guest pipeline, the authoritative sources may be selected email threads, the current episode catalog, an approved fit rubric, and the pipeline table. Public research can extend those sources, but it should be labeled and linked. Unrelated private files are outside the job even if the product can reach them.

Tell the agent how to handle conflicts. If an old note contradicts a newer source, which one wins? If the person in an email cannot be matched confidently to a public profile, should the agent leave the field empty, mark it uncertain, or stop for review?

Google's skills guidance recommends explicit instructions for missing information. The important move is to choose the failure behavior before the agent is under pressure to produce a complete-looking output.

3. State the constraints

Constraints define acceptable methods and qualities.

They may include scope, time, budget, source quality, writing style, privacy, recency, required fields, excluded data, or a maximum number of results. They can also forbid shortcuts that would technically satisfy the outcome while damaging the work.

For public editorial work, a constraint might require primary sources for product claims, prohibit invented facts, preserve a raw transcript unchanged, avoid publishing private contact information, and reject thin pages that repeat another page's search intent.

Write constraints as decisions, not aspirations. "Be accurate" is not testable. "Every material product claim must link to current first-party documentation, and uncertain claims must remain labeled or omitted" gives the agent and reviewer something to inspect.

Do not overload the goal with preferences that do not matter to success. Every constraint creates work and can conflict with another instruction. Keep the ones that protect the outcome, the people involved, or the quality bar.

4. Separate authority from capability

Authority answers what the agent is permitted to change.

An agent may be capable of sending email, updating files, booking meetings, or using a signed-in browser. Capability does not grant permission.

Describe allowed actions, approval-required actions, and prohibited actions in sentences. For the guest pipeline, the agent may read approved messages, research public sources, update a private sheet, and create drafts. It must ask before contacting anyone. It may not book, reject, delete, publish, or expose private details.

Product confirmation prompts are useful, but they are not a complete authority model. A confirmation can appear after the agent has already selected the wrong recipient or used the wrong context. The job definition should prevent the action from becoming the default path.

High-consequence work needs a narrower authority boundary and may require organizational controls beyond the goal itself.

5. Define verification outside the agent's narrative

Verification is the evidence that the outcome exists.

A file inventory can be checked against the filesystem. A research report can be checked by opening its citations. A pipeline row can be checked against the source message and activity date. A scheduled run can be checked through a run record that shows when it started, what changed, and what failed.

Include both positive and negative checks. Positive verification asks whether the promised artifacts exist and meet the acceptance criteria. Negative verification asks whether prohibited actions occurred, expected records were missed, duplicates were created, or private information escaped its boundary.

NIST's AI Resource Center treats testing, evaluation, verification, and validation as parts of operational AI risk management. The seven-part format is Venture Step's synthesis, not a NIST standard, but it follows the same practical premise: trust should be supported by documented evidence rather than the system's confidence.

For recurring work, specify who reviews the evidence and how often. Verification with no owner becomes another unattended output.

6. Add stop conditions

A stop condition tells the agent when progress is no longer responsible.

The agent should stop when a required source is unavailable, identity cannot be resolved, instructions conflict, the requested action exceeds authority, a sensitive category appears, the result would exceed a stated limit, or repeated attempts fail.

Stopping is not the same as abandoning the job. The agent should preserve what it learned, explain the exact boundary, and identify the smallest decision or input needed from the operator.

This matters most for long-running tasks. A recurring agent that keeps guessing after its context becomes stale can turn a small ambiguity into a weekly error.

Include a stop condition for success as well. If the desired state already exists, the agent should verify it and avoid unnecessary changes.

7. Specify the report back

The report should help the operator decide what happens next.

Ask for the final state, the artifacts changed, sources used, unresolved uncertainty, actions withheld for approval, verification performed, failures encountered, and the next review date. For a recurring job, include the previous run and material differences.

Do not require a long narrative when a compact operational report is enough. The report is not the work. It is the interface between delegated work and accountable review.

The operator should be able to distinguish completed, partially completed, and blocked. An agent that reports partial work as success makes every later metric less trustworthy.

A complete goal for a podcast guest pipeline

The following example combines the seven parts without turning the instruction into a stack of empty labels.

Maintain a reviewable list of every active Venture Step guest opportunity in the approved pipeline sheet. Use the selected guest-pitch email threads, current episode catalog, and fit rubric as authoritative context. You may use public first-party sources to verify a person's work, but you must link those sources and label uncertain identity or contact information.

Preserve the source message for every row. Use the approved pipeline states and name the next owner and next action. Do not infer acceptance, rejection, employment, relationships, or contact details when the source does not establish them. Do not send messages, schedule meetings, reject guests, delete records, or publish information. Drafts are allowed only after the recipient and premise are verified.

The task is complete when every in-scope conversation has one canonical row, duplicates are reconciled without losing source links, stale opportunities are surfaced, and a sample of active, dormant, declined, and duplicate cases passes manual review. Stop when identity is ambiguous, a source contains sensitive information outside the task, instructions conflict, or an external action would be required.

Report the rows created or changed, source links used, uncertain matches, drafts awaiting approval, known misses, verification sample, last successful run, and next scheduled review.

Test the goal before scheduling it

Run the goal once on a small known sample. Include a clean case, a duplicate, a missing field, an out-of-scope message, and a case that should trigger approval.

Inspect the result against the source. Confirm that the agent stopped where expected and did not perform a prohibited action. Correct the goal, not only the output, when the same ambiguity could recur.

Only then attach a schedule. Google's Spark schedule documentation notes that runs can be approximate, delayed, or skipped. A recurring goal therefore needs a last-run signal and a stale-state warning in addition to its content checks.

The goal is ready for responsible use when the agent can finish valid cases, expose invalid ones, and leave enough evidence for a person to tell the difference.

E115 is the natural next episode for the distinction between outcome and process goals. E111A shows how durable instructions can live inside a repository rather than one prompt, and E113 expands the problem to autonomous workflow infrastructure. The publishing agent should activate those episode links after their public pages exist.

Sources, test conditions, and updates

This format was developed from Dalton Anderson's E120 Gemini Spark test and Venture Step's content and workflow operations. Product behavior was checked on July 27, 2026 against Google's Spark help, schedule documentation, and skills guidance. Verification context draws on the NIST AI Resource Center. AI assisted with source organization and drafting; Dalton’s transcript and the linked sources control factual claims. The seven-part goal is a Venture Step operating model, not a universal standard or a guarantee against unsafe agent behavior.