Context engineering for AI agents is the work of choosing what an assistant sees before it makes a decision: the goal, instructions, source data, memory, examples, approval rules, budget limits, and recent outcomes.
For a company agent, context is the difference between a chat reply and useful operating work. The assistant needs to know what the business is trying to do, what data to trust, what it is allowed to change, when to ask, and when to stop.
Updated June 22, 2026 by Romain Simon. This guide is based on how win.sh treats one durable assistant per business: goals, editable memory, source data, authority, budgets, approvals, and operating examples.
Author note: Romain Simon builds win.sh for Yuki Capital portfolio operations. The context rules below come from running assistants with editable company memory, authority settings, budget gates, and reviewable traces.
What is context engineering for AI agents?
Context engineering for AI agents is the practice of deciding what an assistant should know, when it should know it, where the information comes from, how fresh it is, and what the assistant is allowed to do with it.
For a business assistant, context usually includes company goals, current priorities, operating rules, customer commitments, decision history, source data, editable memory, examples, budget limits, authority rules, approval requirements, and recent outcomes.
Prompt engineering asks, "How do we phrase the instruction?"
Context engineering asks, "What does the assistant need to know to make the right move?"
That is the practical difference.
Context engineering vs prompt engineering, memory, and retrieval
| Concept | What it controls | Business example | Failure when weak |
|---|---|---|---|
| Prompt engineering | How the assistant follows one instruction | "Write the report in three bullets" | Polished answer, wrong business judgment |
| Retrieval | Which documents or records are fetched | Pricing policy, support docs, customer notes | Missing or stale evidence |
| Memory | What carries forward between runs | Approved refund rule, rejected tone, customer preference | The assistant repeats old mistakes |
| Context engineering | What the assistant sees and may do before action | Goal, source data, memory, authority, budget, examples, stop conditions | Confident work on the wrong goal |
The business context stack
A useful business assistant needs a context stack, not a bigger prompt.
| Layer | What it answers | Example |
|---|---|---|
| Goals | What are we trying to achieve? | "Increase qualified demos without raising CAC." |
| Rules | What must always be true? | "Never promise custom features without approval." |
| Memory | What should carry forward? | "Last week's churn review found onboarding confusion." |
| Source data | What is true right now? | "Stripe MRR is down 4 percent this week." |
| Authority | What can the assistant do? | "Draft refunds, ask before sending." |
| Budget | How much can it spend? | "Use cheap daily checks, stop at the monthly cap." |
| Examples | What does good look like? | "Customer emails should be direct, short, and specific." |
| Source of truth | Which data wins when sources conflict? | "Stripe revenue beats spreadsheet revenue." |
| Stop conditions | When should the assistant stop? | "Stop when data is missing, risk is unclear, or budget is near limit." |
| Recent outcomes | What happened after prior actions? | "Last win-back email recovered one account and annoyed another." |
| Evaluation | How do we know work improved? | "Track approved recommendations, rejected actions, and useful decisions." |
The assistant's answer quality depends on these layers. A long instruction with weak business context still produces weak business work.
What win.sh has learned from business agents
win.sh uses one durable assistant per business, editable memory, approval rules, budget limits, source data, and run traces. The important lesson is simple: context must be owned by the business, not hidden inside a chat. If the owner cannot inspect, correct, or remove context, the assistant eventually acts on stale judgment.
Three lessons show up repeatedly:
- Context without authority creates confident drafts that still need a person to sort risk later.
- Memory without cleanup turns old preferences into bad instructions.
- Budget without stop conditions lets routine checks become expensive research.
That is why win.sh treats context as an operating layer: goals, source data, memory, authority, budget, approvals, and review all move together.
Goals give the assistant direction
The assistant should not infer the company goal from a vague task.
Bad context:
Help us grow.
Useful context:
This quarter, the company is focused on increasing qualified demos from founder-led content and partner referrals. Paid acquisition is paused until CAC is below target. Prioritize actions that improve demo quality, follow up with warm leads, or reduce founder time spent on repetitive sales admin.
Good goal context includes the metric that matters, the current strategy, tradeoffs already decided, the time horizon, work the assistant should prioritize, and work it should avoid. Without this, an assistant invents its own definition of success.
Rules turn founder judgment into operating context
Every company has rules that people know but systems do not.
Examples:
- Do not discount annual plans without founder approval.
- Do not send legal language to customers.
- Do not mention unreleased features in public.
- Do not email investors after 6pm.
- Do not create tasks unless they have an owner and due date.
- Do not change pricing copy without review.
Rules should be written as operating constraints, not vague preferences. "Be careful with customers" is not enough. "Ask before sending messages to customers on enterprise plans" is better.
For risky workflows, rules should connect directly to authority. The assistant can draft. The owner approves. The assistant learns from the decision.
Memory makes context compound
A company context AI agent should not start from zero every morning.
It should remember decisions, corrections, failures, approvals, and customer commitments. That is why business agent memory matters. Memory is not chat history. It is the durable operating record the assistant uses to avoid repeating work and to act with better judgment next time.
Useful business memory looks like this:
- "The founder rejected long recap emails. Future recaps should lead with three bullets."
- "Customer Acme is sensitive to billing surprises. Ask before any billing related message."
- "The onboarding drop happened after the pricing page change, not after the email campaign."
- "Refunds under $100 can be drafted automatically, but sending still needs approval."
Memory also needs correction. If the assistant remembers something wrong, the owner must be able to edit or delete it. Hidden memory is risky. Editable memory is useful.
Source data grounds the assistant in reality
Business assistants need current data, not just stored knowledge.
Source data can come from Stripe for revenue, analytics tools for traffic, CRM systems for pipeline, support tools for tickets, docs for policies, and task systems for ownership and deadlines.
Bad source context:
Revenue is down.
Useful source context:
Stripe shows MRR down 4 percent since June 15. The drop is from three cancellations on the starter plan. No enterprise accounts churned. Analytics traffic is flat, so this looks like retention, not acquisition.
That changes the action. The assistant should not propose more ads. It should inspect onboarding, cancellation reasons, and starter plan value.
Authority is part of context
A business assistant that knows the company but has no authority model is still unsafe.
Authority context tells the assistant what it can do alone, what it can draft, and what it must ask before doing. This is where human in the loop AI agents become practical instead of ceremonial.
| Level | Meaning | Example |
|---|---|---|
| Read only | The assistant can inspect and summarize. | "Check revenue and explain what changed." |
| Ask first | The assistant can prepare work but needs approval. | "Draft a refund reply, then wait." |
| Autonomous | The assistant can act within a narrow rule. | "Create an internal task for invoices missing tax details." |
Authority should be specific by tool, workflow, customer type, and risk level. Raise authority only when the workflow is predictable, measurable, and reversible.
Budget context prevents expensive curiosity
A business assistant spends money when it works. That spend needs context too.
The assistant should know monthly budget, per-run budget, task priority, when to use cheaper work modes, when to stop, and when to ask for approval.
AI agent cost control is part of context engineering because cost changes behavior. A daily metrics check should not use the same budget as a major competitive research run.
Good budget context sounds like this:
This assistant has a $100 monthly budget. Daily monitoring should stay cheap. Use deeper analysis only when revenue changes more than 5 percent, churn spikes, or the owner asks for a full review.
Budget context keeps curiosity from turning into cost.
Context mistakes that make agents unreliable
Most unreliable agents have a context problem before they have a model problem.
Watch for:
- stale memory
- conflicting instructions
- untrusted source data
- hidden context the owner cannot inspect
- over-broad authority
- no budget stop
- no record of what changed
- no evaluation of approved, rejected, or ignored recommendations
The fix is not to add more text. The fix is to decide what the assistant should trust, what it should ignore, what it may do, and when it must stop.
Examples teach taste
Examples are one of the most underrated parts of AI agent context engineering. They teach taste and judgment faster than abstract instructions.
Useful examples include approved customer emails, rejected emails with reasons, good weekly reports, bad weekly reports, accepted decisions, rejected decisions, task formats the company likes, and escalation messages that worked.
Bad instruction:
Write in our brand voice.
Better context:
Approved style: "Revenue dipped 4 percent. Three starter customers churned. No enterprise accounts moved. I would check onboarding first, not acquisition." Avoid vague lines like "There may be several possible causes."
The second version gives the assistant a pattern it can reuse.
Example: SaaS revenue assistant
Weak setup:
Check Stripe and tell me if anything changed.
Strong context setup:
- Goal: protect MRR and catch retention problems early.
- Rule: do not contact customers without approval.
- Memory: starter plan churn rose after onboarding was shortened.
- Source data: Stripe revenue, analytics activation events, support tickets.
- Authority: inspect data, draft customer follow-ups, ask before sending.
- Budget: cheap daily checks, deeper analysis only if MRR changes by more than 3 percent.
- Example output: three bullets, one risk, one proposed action, no long narrative.
Now the assistant can do useful work:
MRR is down 3.8 percent since Friday. The movement came from two starter plan cancellations. Both accounts had low activation and no support tickets. This matches the onboarding risk we saw last week. I drafted a short win-back email for review and created an internal task to inspect the activation step.
That is a business assistant, not a chatbot.
How this fits an AI business OS
An assistant with context is useful. A business with durable context, budgets, approvals, memory, and operating loops starts to look like an AI business OS.
The difference is continuity. A chat session helps with one task. An AI business OS keeps the business context alive across days, tools, decisions, and workflows. It knows what changed, what was approved, what failed, and what the owner wants watched next.
The business does not need ten disconnected assistants, each with its own instructions. It needs one coherent operating layer where context compounds.
For implementation, read how to build an AI agent for business. For operating patterns, read autonomous business agents and AI agents for business operations.
Context engineering checklist
Use this checklist before trusting an assistant with recurring work:
- Does the assistant know the current business goal?
- Does it know the rules it must never break?
- Does it have access to the right source data?
- Does it know which data source is authoritative?
- Can the owner edit its memory?
- Does it know what actions require approval?
- Does it have a monthly and per-run budget?
- Does it know when to stop?
- Does it have examples of good work?
- Does it record decisions and outcomes?
- Does it learn from corrections?
- Can the owner inspect what context was used?
If the answer is no, the issue is not the model. The issue is the context layer.
The takeaway
Context engineering for AI agents turns goals, rules, memory, source data, authority, budgets, and examples into the operating layer an assistant needs to act safely.
Prompt engineering can improve a reply. AI agent context engineering improves repeated work.
For business agents, that is the whole game. The assistant should know what the company wants, what it has learned, what data to trust, what it can do, what it must ask, and when the work is no longer worth the cost.
Further reading: Anthropic's effective context engineering for AI agents, LangChain's context engineering docs, Manus's lessons from building Manus, and Weaviate's context engineering overview are useful technical companions to the business operating model here.