Context + Prompt = Anything a Computer Can Do

By Josiah Hunter7 min read

Context and a prompt can direct extraordinary computer work, but only when tools, permission, an action loop, and verification complete the equation.

context + prompt = anything a computer can do

That is the useful version of the idea, not the complete one.

Context tells the system what world it is in. The prompt names the change you want. Tools and permissions decide whether the system can touch that world at all. An action loop lets it respond to what happens next. Verification decides whether you should believe the word done.

The fuller version looks like this:

verified computer work = context + prompt + tools + permission + action loop + evidence

That equation is less elegant. It is also much better at explaining why an AI agent succeeds, stalls, or confidently finishes the wrong job.

Context is state, not stuffing

People often use context to mean “the long material I pasted before my question.” That is part of it, but it misses the operational point.

Anthropic's context-engineering guidance describes context as the information available to the model during inference. For an agent, that can include system instructions, tools, external data, message history, file names, prior results, and the current state of the work.

Useful context answers questions such as:

  • Which project am I changing?
  • What has already happened?
  • Which constraints still apply?
  • What does the current system look like?
  • Which facts are authoritative?
  • What would count as a conflicting instruction?

Context is not valuable by weight. More information can dilute the signal the agent needs. A 200-page dump that contains three decisive facts may be worse than those three facts, their sources, and a path for retrieving more when needed.

The objective is not maximum context. It is the smallest high-signal state that lets the agent make the next good decision.

A prompt names the change

If context describes the world, the prompt describes the desired difference between the current world and the result.

“Review this repository” names an activity. “Find why scheduled articles appear before their release time, correct the publishing path, and prove the intended URL remains unavailable until Monday at 9:00 AM Chicago time” names a state change and its evidence.

That distinction matters because language models are very good at producing something that resembles work. A summary can resemble a review. A proposed patch can resemble a fix. A confident status line can resemble verification.

A strong prompt reduces that ambiguity. It identifies the outcome, the boundaries, the allowed side effects, and the observation that will count as success. It does not need to dictate every step. It does need to make the destination inspectable.

Tools define the action ceiling

A prompt cannot open a file the system cannot see. Context cannot publish to an account the system cannot access. Perfect wording cannot create a missing API, credential, browser, compiler, or approval.

Tools bridge that gap. Anthropic describes tools as the contract between an agent and its information or action space. OpenAI's practical agent guide makes a similar separation: the model reasons, instructions guide behavior, and tools retrieve information or take action in external systems.

That gives us a useful diagnostic rule:

If the agent understands the request but cannot change the state, inspect the tool boundary before rewriting the prompt.

Sometimes the missing tool is obvious. The agent can explain a spreadsheet but cannot edit it. It can draft an email but cannot send it. It can write an article but cannot touch the publication repository.

Other times the tool exists but exposes the wrong level of control. A publishing tool that can push a page but cannot check discovery surfaces is enough to create a URL, not enough to prove a release. A file tool that can overwrite an entire directory when only one note should change creates capability without a safe boundary.

The set of tools defines what is possible. The design of those tools shapes what is safe and verifiable.

Permission is separate from capability

An agent may be technically able to do something and still lack authority to do it.

That separation is essential. Reading a task is not permission to complete it. Drafting an article is not permission to publish it. Access to a repository is not permission to push unrelated changes. A tool can expose an action while policy, user intent, or a scoped approval determines whether the action is allowed now.

Good agent work preserves that distinction in the context:

  • allowed: prepare and package an article today;
  • allowed later: publish one exact revision after a specified time;
  • prohibited: make it visible early;
  • still open: perform an independent verification the next day.

Permission is not friction added after the intelligent work. It is one of the inputs that defines the correct work.

The loop turns intent into state change

Real computer work rarely succeeds in one model response. An agent inspects the current state, chooses an action, observes the result, updates its understanding, and tries the next bounded action.

The ReAct research formalized the value of interleaving reasoning with task-specific actions. Actions let a model gather information from an external environment; the returned information changes the next decision.

The important part is not the label. It is the feedback.

Suppose an agent is preparing an article to appear on Monday at 9:00 AM:

  1. Context: It receives the article intent, the current repository, the publication workflow, the timezone, and the rule that the page must remain hidden beforehand.
  2. Prompt: Complete the article today, configure delayed publication, and prove the public surfaces remain hidden.
  3. Tools: It can research, write run artifacts, package a revision, inspect the site, register a future wake-up, and use the scoped publisher.
  4. Permission: It may prepare now and publish only at or after the specified instant.
  5. Loop: Each controller stage validates the artifact and either advances or returns a repair finding.
  6. Evidence: Before release, the intended URL returns 404 and the slug is absent from the homepage, blog, feed, and sitemap. After release, the exact revision returns 200 and appears on every required discovery surface.

The prompt did not do all of that. The surrounding system did. The prompt directed it.

Verification earns the word done

Tool execution is not proof of the intended result.

A file-writing command can succeed while writing the wrong file. A deployment can succeed while serving an older revision. A scheduled job can exist with the wrong timezone. A page can return 200 while remaining absent from the feed and sitemap.

Verification compares an observable state with the requested state. It turns “the action ran” into one of two conclusions:

  • the evidence matches, so stop;
  • the evidence does not match, so repair or report the exact boundary.

This is why I distrust workflow language that ends with “generated,” “deployed,” or “completed” without naming the thing a person can inspect. The useful evidence is usually concrete: a file hash, a test result, an application readback, an HTTP status, a canonical URL, a timestamp, or the absence of a page that is supposed to remain hidden.

The right verification follows the claim. If you claim a page is live, inspect the live page. If you claim a task is complete, read back its state from the task system. If you claim something is scheduled, read back the saved time and timezone.

The boundary of “anything”

“Anything a computer can do” still has boundaries.

The action must be digitally representable. The system needs an interface to it. The agent needs sufficient context to choose correctly, permission to act, and feedback that exposes the result. Some work also needs human judgment that should not be silently replaced by a model's confidence.

Within those boundaries, the ceiling is remarkably high. Code can be changed and tested. Documents can be transformed. Interfaces can be operated. Research can be gathered and reconciled. Records can be updated. A publication can move from an idea to a verified URL.

But the power does not come from a magic sentence. It comes from connecting language to a well-bounded system.

A six-question preflight

When an agent stalls, or when I am about to give one an ambitious job, I now ask six questions:

  1. Context: What can the agent see, and which source wins if the inputs disagree?
  2. Prompt: What observable state should be different when the work is finished?
  3. Tools: Which information and action interfaces does the agent actually have?
  4. Permission: Which of those actions is it authorized to take, and when?
  5. Loop: What feedback will return after each action so it can continue or repair?
  6. Evidence: What exact observation will justify saying the outcome passed?

Better prompting helps. Better context helps. Neither can substitute for a missing tool, a missing permission, or missing evidence.

So I still use the shorter equation. It points in the right direction:

context + prompt = anything a computer can do

I just keep the rest of the system in view. Context defines the world. The prompt defines the change. Tools and permission define the reachable actions. The loop makes progress. Verification earns completion.