Context engineering makes business agents useful

The prompt is only a small part of a production business agent. The difficult work is selecting information, tools, state, permissions, and stopping rules.

LeanOrchestr August 12, 2026 7 min read

The prompt gets too much credit.

For a production business agent, the difficult questions come before and after the instruction:

What may it see? Which source is current? Which tools may it call? What state must survive between steps? When should it stop? Which action needs approval? How will the team know it worked?

That wider system is context engineering.

The prompt is one input

A prompt can define the role, task, output, and important boundaries.

It cannot make an outdated policy current. It cannot preserve a source permission that was removed during ingestion. It cannot provide a missing customer history or repair a tool that returns ambiguous fields.

Useful behavior depends on the full package the model receives:

Instructions.
Relevant evidence.
Conversation and workflow state.
Available tools.
Business rules.
Examples.
Action boundaries.

Changing one sentence in the prompt may help presentation. It rarely fixes a broken system around it.

Give the model only what the task needs

An account brief does not need the employee handbook. An onboarding assistant does not need access to private finance records. A support workflow does not need every CRM field and project tool action.

Scope improves both safety and performance.

For each workflow, define:

The approved information sources.
The minimum tool set.
The user or service identity.
The state that must be remembered.
The output or action expected.
Conditions that require a person.

Anthropic’s context engineering guidance describes context as a finite resource. Poor tool use, irrelevant information, and dead ends consume that resource without moving the task forward.

State is different from knowledge

Company knowledge includes policies, customer history, and past decisions.

Workflow state describes what is happening in this run.

For example, a contract review agent may need to remember:

Which agreement is being reviewed.
Which clauses have already been checked.
Which questions remain open.
Which approval is pending.
Whether a proposed change was accepted.

If that state is stored only inside a long conversation, it becomes fragile. Persist important progress in structured records the workflow can resume and audit.

Tools need clear descriptions and narrow outputs

Models choose tools based on the name, description, schema, and current context.

Two vague tools called search_records and find_data create confusion. A tool that returns hundreds of fields wastes context. An action tool without clear consequences increases risk.

Design tools around business intent:

find_active_customer_contract
get_project_changes_since_date
propose_crm_update
request_discount_approval

Return the fields required for the next decision and a source reference. Keep destructive actions separate from read operations.

Approval belongs inside the workflow

Telling a model “ask before doing anything sensitive” is weaker than enforcing the boundary in code.

Define which actions require approval and make the tool unavailable until that approval exists. Record who approved, what they saw, and what action followed.

The model can prepare the recommendation. The system controls whether the action is allowed.

Evaluation begins with the business outcome

An agent that produces fluent output may still fail the operation.

A client brief is successful when it includes current commitments, open risks, owners, and source links. A meeting workflow is successful when confirmed actions become the right tasks without creating duplicates. A support workflow is successful when it uses approved facts and escalates cases outside its scope.

Anthropic’s evaluation guidance recommends tests that reflect the actual workflow. Useful evaluation checks whether the system did what was asked, avoided damage, and met the quality required for the task.

Build a small set of real cases before launch. Keep them as regression tests when the model, prompt, sources, or tools change.

Start simpler than the demo

Many tasks do not need an autonomous agent.

Anthropic recommends starting with simple model calls, retrieval, and predefined workflows, then adding agentic behavior only when simpler systems fall short.

That approach fits business operations well.

Begin with one clear trigger, a bounded context set, a proposed output, and a human approval. Observe where judgment is genuinely needed. Add autonomy around those decisions, not around the entire process.

Build the system around the model

The model matters. It is not the whole product.

The Business Brain combines approved sources, retrieval, permissions, state, tools, approvals, logs, and evaluation around Claude. That is what turns a convincing response into a maintainable company workflow.

The prompt tells the model what you want.

Context engineering gives it a fair chance to do the work correctly.

Questions people ask

What is context engineering?

Context engineering is the design of what information, tools, state, instructions, permissions, and history a model receives for a specific task.

How is context engineering different from prompt engineering?

Prompt engineering focuses on instructions and examples. Context engineering covers the larger system that retrieves evidence, manages memory and state, exposes tools, applies access rules, and evaluates results.

What should companies build first?

Start with one valuable workflow, a clear success test, a small set of approved sources, and defined approval boundaries. Add autonomy only after the simpler workflow is reliable.