Steer AI agents with outcomes and anchors

AI agents keep getting more capable, but the best runs still come down to an old, human discipline. Say what done means, then point the agent at the right evidence.

An outcome is what must be true when the work is finished. An anchor is the evidence that keeps the agent grounded while it gets there: source files, API docs, screenshots, logs, failing tests, examples, constraints, policies, the patterns you accept, the patterns you reject, and the exact thing that needs to change.

Take those anchors away and the agent guesses. Sometimes it guesses confidently. Sometimes it even produces something that looks impressive. None of that makes it correct.

A generic prompt feels like magic for about five minutes, then it gets expensive.

A task alone is too vague

“Improve the onboarding flow” is a task. It points the agent in a direction and gives it no finish line.

“Reduce the onboarding form from five steps to three, keep the existing validation rules, preserve the current analytics events, and verify the mobile layout at 390px and desktop at 1440px” is an outcome. Now there’s a target, the constraints are spelled out, and there’s something concrete to check against.

You see the same thing outside software:

• “Summarise this policy” is a task.
• “Turn this policy into a one-page staff checklist, keep the legal terms intact, and flag any step that needs manager approval” is an outcome.

Word count has nothing to do with it. What matters is whether the agent can tell when it has actually succeeded.

OpenAI’s prompt engineering guidance and Anthropic’s Claude prompting guidance keep landing on the same point. Clear instructions, relevant context, examples and structured expectations beat vague intent. Tool use raises the stakes, because now the model can act on the instruction rather than just answer it.

Anchors stop the agent inventing the job

An anchor is anything that narrows the agent’s idea of reality.

For a coding agent, good anchors include:

• the exact files or modules involved
• the failing test output
• the route, endpoint, component or screen under discussion
• a known-good implementation elsewhere in the repo
• screenshots of the broken state and the expected state
• the project conventions in AGENTS.md, README.md or local docs
• commands that prove the work is finished

For a business workflow agent, good anchors include:

• the policy or procedure it must follow
• examples of approved and rejected answers
• the source record it is allowed to use
• the escalation rule when it is unsure
• the format the output must match
• the person or system that reviews the result

Anchors stop the agent from solving a tidier, imaginary problem instead of the messy one actually in front of it.

Good prompts point at evidence

This is the kind of instruction that tends to work:

Goal: make the invoice import tolerate missing optional fields without changing required-field validation.

Anchors:
- Start in app/imports/invoices.ts and tests/imports/invoices.spec.ts.
- Use the old CSV importer in legacy/importers/csv-invoices.ts as the behaviour reference.
- The failing case is attached in missing-optional-fields.csv.
- Required fields are invoice number, supplier, total and due date.
- Optional fields must remain blank, not become "unknown".

Done when:
- Existing invoice import tests pass.
- Add a regression test for the attached CSV.
- Show the test command and result.

That gives the agent a path through the work, and it gives you a way to judge the answer when it comes back.

Compare it with “Fix the invoice importer.” The agent might open the wrong file, widen the change, invent validation rules, or make the test pass by quietly weakening the test. A vague instruction rewards exactly that.

Agents need permission boundaries

A tool-using agent can browse files, call APIs, run commands, open browsers, create drafts, change data and talk to other systems. That makes the surrounding context more important, not less.

OpenAI’s Agents SDK docs are built around agents, tools, guardrails and workflow state. Anthropic’s tool use docs show the same pressure from the other side. Once a model can call tools, the system around it has to decide what each tool is allowed to do, what information it gets, and how the results come back.

Most of a useful agent system is harness work. The model is one part of the product. The rest is permissions, data access, logging, retries, escalation, cost control, evaluation and review.

The boundaries are specific to the job. A finance assistant might read invoices and draft a reconciliation note, but never mark an invoice as paid. A support assistant might draft replies from approved knowledge articles, then hand off anything about refunds. A software agent might edit code and tests inside one repo, but never deploy without a human.

Whatever the boundary is, set it before the agent starts, not after.

We use this pattern at Rangefront Labs

We run AI agents across software work, research, content preparation and internal workflow tasks. The runs that pay off rarely begin with a clever prompt. They begin with anchors.

For code that is the actual repo, the failing command, the working example, the screenshot, the route, the data file and the project rules. For writing it is the existing site voice, the banned phrasing, the source links, the point of the article and the reader’s actual problem. For product work it is the workflow being changed, the system of record, and the action that would make the work worth doing.

Our AI project guidance keeps landing back on ownership, review and data boundaries. A prompt is not a strategy, which we got into over in prompts are not an AI strategy. Agents only help when they hang off a process that already knows what good looks like.

A simple operating rule

Before you hand work to an agent, write three short sections.

1. Outcome. What should be true when this is finished?
2. Anchors. What sources, examples, files, records, screenshots or rules should keep the agent grounded?
3. Evidence. What proof should the agent return so a human can trust the result?

A little structure changes how the work goes. The agent wanders less, polishes the wrong thing less often, and hands you something you can review quickly.

The teams getting value out of agents aren’t the ones writing the longest prompts. They’re the ones who can describe an outcome, supply the anchors and verify the result, without pretending the model owns the decision.