Context + Prompt = Anything a Computer Can Do

A prompt can name a change but cannot complete it alone; context, tools, permission, feedback, and claim-matched verification turn an instruction into trustworthy computer work.

Published August 31, 2026. Revised October 9, 2026.

An AI assistant can understand your request and describe the correct result, yet still fail to deliver it. It may lack access to the current state, an interface that can change that state, permission to use the interface, feedback from its actions, or evidence that the result matches what you asked for.

The title compresses that gap into a short equation:

context + prompt = anything a computer can do

The equation is useful shorthand, not a literal claim that words alone perform computer work. Context supplies state and constraints. The prompt describes the desired change. Tools expose possible actions, while permission determines which actions are authorized. A feedback loop lets the system respond to what happens. Verification compares the requested state with suitable evidence.

When work stalls, the fuller practical synthesis is more useful:

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

Together, those parts determine what work is reachable. If one is missing, rewriting the prompt may improve the response without fixing the workflow.

Start with a state transition

Context is more than background material pasted above a question. Anthropic describes context as the tokens available when a language model is sampled and context engineering as curating the information supplied during inference. Its examples include system instructions, tools, external data, and message history.

Operational work also requires the relevant current state: which project is in scope, what has already happened, which constraints still apply, and which source wins when two inputs disagree. Those are practical examples for assembling context, not items attributed to Anthropic’s enumeration.

The objective is not maximum context. It is a sufficiently complete, high-signal context for the next decision. A large collection of loosely relevant material can hide the decisive constraint, while a smaller set of authoritative inputs can make the next action clear.

Consider one hypothetical example throughout this article. An article is supposed to become public on Monday at 9:00 AM Chicago time and remain unavailable before then. No real schedule is being created here. The example only shows how the parts of the workflow depend on one another.

The context would need to identify the correct article, its approved content, the current repository or publishing state, the timezone, the required discovery surfaces, and the rule against early visibility. Without that state, an agent could edit the wrong revision, interpret 9:00 AM in the wrong timezone, or overlook a feed that exposes the article early.

The prompt names the requested difference between the current state and the desired one. “Work on this article” names an activity. “Prepare the approved article for Monday at 9:00 AM Chicago time, keep it unavailable beforehand, and verify the required public surfaces after release” names an inspectable result and its boundaries.

Generated output can resemble completed work even when no state has changed. A summary can look like a review, a proposed patch can look like a fix, and a status line can look like verification. A useful prompt identifies the outcome, allowed side effects, timing constraints, and the observation that would count as success.

Tools and permission define reachable action

A clear request does not create an action interface. A prompt cannot open a file the system cannot see, update a service it cannot reach, or inspect a public surface it has no way to query.

Anthropic describes tools as defining the contract between an agent and its information or action space. OpenAI’s practical guide to building agents separates the model’s reasoning and decisions, instructions that define behavior and guardrails, and tools that act in external systems.

In the hypothetical publication workflow, the agent might need interfaces that can read the current source, write the approved revision, validate the package, configure delayed publication, and inspect both the canonical page and its discovery surfaces. If the available tool can write an article but cannot interact with the publication system, the agent can prepare the content. It cannot perform the release.

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

Sometimes the missing interface is obvious. An assistant 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 tool gaps appear only when you compare the interface with the whole requested state. A publisher that can create a page but cannot inspect the homepage, blog listing, feed, or sitemap may support release without supporting complete verification. A file tool that can replace a directory when only one article should change exposes technical capability without a sufficiently safe boundary.

Capability does not establish permission. An interface may make an action possible while the user’s instruction, policy, or approval limits whether it may be used. In the hypothetical example, the agent could be authorized to prepare and validate the article now while release remains prohibited until the specified time. Access to the publication tool would not erase that timing rule.

Available access is not standing authority. Permission determines which otherwise possible action is correct now. When the required authority is absent or ambiguous, the proper result is a bounded stop or a request for approval, not an unauthorized state change.

Feedback carries the work forward

Computer work usually changes the conditions for the next decision. A validator might return an error, a write operation creates new file state, and a publication system returns a saved configuration. An inspection may reveal that one surface differs from the others.

OpenAI’s guide describes agents using tools to gather context or take action as workflow state changes, with single-agent workflows executing in a loop. The ReAct paper studies reasoning and task-specific actions interleaved so that observations from external sources can inform updated plans. ReAct supports this reasoning-action-observation pattern; it does not establish the permission or verification framework used here.

In the hypothetical workflow, the agent first inspects the current article and release configuration. It prepares a bounded change, then receives validation results. If the package reports a broken canonical link, the next action becomes “repair the link and validate again,” rather than “continue toward release.” If the saved timezone reads UTC instead of America/Chicago, the returned state exposes a mismatch that must be corrected before the workflow can proceed.

Those observations keep the action sequence connected to the state it is changing. Without them, the system can issue actions but cannot reliably adapt when an assumption fails.

Feedback informs the next action. Verification answers a different question: does the observable result support the exact completion claim?

A successful tool call answers only a narrow question about execution. It does not prove that the intended outcome exists. A file-writing command can succeed while targeting the wrong file. A deployment can succeed while serving an older revision. A delayed-release configuration can be saved with the wrong timezone. A page can return an HTTP 200 response while remaining absent from the required discovery surfaces.

Evidence must match the claim:

• If the claim is that a release is configured for the correct time, read back the saved date, time, and timezone from the system that owns the schedule.
• If the claim is that the article remains hidden before release, inspect the intended URL and every surface that could reveal it.
• If the claim is that the article is public after release, inspect the canonical page and confirm its required appearances on the public homepage, blog, feed and its repository source, and sitemap and its repository source.
• If the claim is that the approved revision is live, compare observable content or a suitable revision identifier rather than relying on a deployment command’s success message.

These are possible checks within the hypothetical example, not evidence that such a publication occurred. “The action ran” and “the requested state now exists” are different claims.

The boundary of “anything”

“Anything a computer can do” still has conditions. The work must be digitally representable and exposed through a suitable interface. The agent needs enough current context to choose an action, authority to take it, and feedback that reveals the resulting state. Completion also needs an observation capable of testing the claim.

Some decisions require human judgment or approval that should not be replaced by model confidence. Other tasks are only partly reachable because the available tool supports preparation but not execution, or execution but not adequate inspection.

Within those boundaries, the range is substantial. Code can be changed and tested. Documents can be transformed. Interfaces can be operated. Records can be updated. Research can be gathered and reconciled. The work becomes reachable when language is connected to a bounded system whose actions and results can be inspected.

A six-question preflight

When an AI-assisted workflow stalls, ask:

1. Context: What can the agent see, what is the current state, 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 available actions is it authorized to take, and when?
5. Loop: What feedback will return after each action so the agent can continue, repair, or stop?
6. Evidence: What exact observation is suited to the completion claim?

Better wording can clarify the destination. It cannot supply a missing interface, authority, feedback path, or suitable observation.