Context Engineering, Model Routing, Cost Control, and Scaling

An agent can only reason over the information that is available in its current context. That context is larger than the visible conversation. It may contain:

• The platform's system prompt.
• Global instruction files.
• Local project instruction files.
• Memory files.
• Skill names and descriptions.
• Detailed skill instructions that have been invoked.
• Tool definitions.
• The active user request.
• Conversation history.
• File content.
• Research results.
• Browser observations.
• Command-line output.
• Error messages.
• Outputs returned by subagents.

Every component consumes tokens. The agent is not given an unlimited working space, so context must be managed as a finite resource.

This creates two connected optimization problems.

The first is quality. As the context becomes longer, the model may have more difficulty maintaining attention on the most important information. Earlier requirements can become harder to preserve. Unnecessary material can compete with the current task.

The second is cost. More tokens require more model processing. A large context may be processed repeatedly as the conversation continues, so information that appears harmless can become expensive when it is included in many calls.

Context engineering is therefore the discipline of deciding what must remain immediately available, what can be stored elsewhere, what should be retrieved only when needed, and what should be summarized or removed.

A token is not the same as a word. A practical approximation is that one token represents about 0.7 words, although the exact relationship depends on the text.

Agent models are described with context capacities ranging from hundreds of thousands to approximately one million tokens. A 200,000-token context therefore represents a very large amount of text, but it is still finite.

The raw maximum can be misleading. The user does not begin with the full context window available. System instructions, memory, tools, and skills may consume a significant amount before the first meaningful message is sent.

A large capacity also does not mean that filling the entire window is desirable. The objective is not to maximize token usage. The objective is to give the model the smallest amount of information that is sufficient for high-quality work.

A key operating principle is that model quality often declines as the active context becomes longer.

At the beginning of a task, the model has a relatively clean view of the objective. After many tool calls, corrections, failed attempts, long outputs, and side discussions, the context can become crowded. The system must separate current requirements from obsolete information, errors, dead ends, and historical detail.

Illustrative numbers are used to make the point. A task that performs very well near the beginning of a context may perform substantially worse near the limit. The exact percentages are not presented as measurements. The practical conclusion is that a longer context is not automatically a better context.

Several mechanisms contribute to the problem:

• Important instructions compete with irrelevant detail.
• Old plans remain present after the strategy has changed.
• Tool outputs can be extremely large.
• Repeated content creates redundancy.
• Persistent instruction files may contain too many rules.
• The model carries failed attempts that are no longer useful.
• The user may assume the model still remembers a detail that was compressed or obscured.

The correct response is proactive context design rather than waiting for the window to fill.

A context-inspection command can show how tokens are being used inside an agent environment.

In one example, a fresh session has used approximately 9,000 tokens before any meaningful conversation has occurred.

The breakdown includes approximately:

• 4,900 tokens for the system prompt and instruction layer.
• 2,000 tokens for memory files.
• 1,700 tokens for skills.
• A very small number of tokens for the visible conversation.

The exact values are specific to that workspace, but the lesson is general. A system can spend a meaningful portion of its context on invisible infrastructure before the user begins the task.

This is not necessarily waste. The instructions, memory, and skills can make the agent more capable. The problem appears when the stored material is poorly organized or larger than its ongoing value.

A rule file that prevents repeated mistakes may justify its cost. A collection of outdated, conflicting, or rarely relevant rules may not.

Tools are part of the agent's operating system. A browser tool may expose actions such as:

• Click an element.
• Drag an item.
• Read a console message.
• Open a page.
• Take a screenshot.
• Enter text.

The agent needs descriptions of these actions so it knows what capabilities are available and how to use them. Those descriptions consume tokens.

The same is true for file tools, search tools, command-line tools, model endpoints, and APIs. A large toolset gives the agent more power but also increases the size of the operating context.

This creates another design trade-off:

• Too few tools limit the agent's ability to act.
• Too many always-loaded tools consume context and may make selection more difficult.

The solution is similar to skill management: expose what is necessary, keep descriptions compact, and load specialized capabilities when the task requires them.

When the context approaches its limit, agent platforms use a process commonly described as compaction or compression.

Before compaction, the model may have access to the complete conversation history. Every message, tool call, output, and correction is present.

At a threshold below the absolute limit, the system compresses a large portion of the history. It summarizes and densifies the information so the conversation can continue with fewer tokens.

The process can be visualized as a press compressing a large block of context into a smaller block. Information that previously occupied most of the window may be reduced to a much smaller fraction.

Compaction makes long-running sessions possible, but it is not lossless. The system may:

• Remove detailed tool outputs.
• Collapse several messages into a summary.
• Omit a minor decision.
• Lose the wording of an important correction.
• Preserve the result while dropping the path used to reach it.
• Remove an earlier detail that becomes relevant later.

The problem is not that compaction always fails. The problem is that the user may not know which detail was lost.

Compaction attempts to preserve meaning in fewer tokens.

A simple sentence such as "Hello, how are you doing?" can be compressed into "Hi, how are you?" The meaning remains similar while the representation becomes shorter.

The same idea is applied across a much larger conversation. Repetition is removed, detailed sequences are summarized, and information is rewritten more densely.

This increases information density, but it also changes the context. A summary cannot preserve every detail of the original. A complex tool result or technical decision may be reduced to a general statement.

For this reason, critical project information should not depend entirely on a long conversation history. Important requirements, decisions, and state should be stored in deliberate files or structured records that can be re-read when needed.

The iceberg technique provides a mental model for strategic context loading.

Only a small portion of an iceberg is visible above the water. A much larger body exists below the surface.

In an agent system, the information above the waterline is immediately present in the active context. It may include:

• Essential global rules.
• Essential local rules.
• Compact memory.
• Current task context.
• The active file or relevant file segment.
• The current definition of done.
• The most important recent tool results.

The information below the waterline is not loaded in full. It remains accessible through tools. It may include:

• The complete codebase.
• Large documents.
• Detailed research files.
• The full git history.
• Web data.
• Large tool outputs.
• Complete skill instructions.
• Archived decisions.

The agent does not need all of this information at every moment. It needs the ability to retrieve the correct part when it becomes relevant.

The operating principle is:

Keep critical active information in context. Keep the larger knowledge base accessible on demand.

Naive context loading places the full information set into the prompt. Strategic context loading stores the ability to access the information.

A model does not need every file in a repository pasted into its context. It needs file-reading and search tools.

It does not need the complete contents of every large document. It needs a way to locate the relevant section.

It does not need the entire internet. It needs search and retrieval capabilities.

It does not need every skill loaded in full. It needs a compact description of the available skills and a way to invoke the appropriate one.

It does not need every historical version of the code. It needs access to the project history when the history is relevant.

This is one of the most important context-engineering principles: capability to retrieve is often more valuable than permanent inclusion.

Suppose a code file contains 10,000 tokens, but the agent only needs one function occupying 2,000 tokens.

Loading the complete file wastes context and introduces unrelated material. A search tool can locate the function and return only the relevant section plus enough surrounding text to understand it.

The same process can operate across a codebase:

1. Search for a filename, function name, class, phrase, or pattern.
2. Identify likely files.
3. Read the most relevant section.
4. Expand the range only if additional context is required.
5. Avoid loading unrelated files.

This is a successive narrowing process. The agent begins with a broad search and progressively focuses on the exact information required for the next decision.

Web access follows the same pattern.

The agent does not begin with all web content in its context. It begins with a query. The search returns candidate links or summaries. The agent evaluates which result is most relevant, reads that result, and expands only when needed.

A practical sequence is:

1. Search for the topic.
2. Inspect the returned titles or URLs.
3. Select the most relevant result.
4. Read the relevant portion.
5. Search again only if the answer remains incomplete.

This keeps unrelated web content outside the active context.

Skills use the same iceberg design.

The structured header at the beginning of a skill contains compact metadata such as its name and description. This small section can remain available so the agent knows the skill exists.

The full procedure is loaded only after the agent decides the skill is relevant.

This prevents a large library from consuming the full context window. It also encourages precise skill descriptions. The description must be clear enough for the agent to choose correctly without reading the complete file.

Tool results can be much larger than the information needed for the next step.

A browser screenshot analysis may produce a long description. A command may return thousands of lines. A research tool may retrieve a large document. A subagent may generate a detailed report.

The system can preserve a concise summary of the result while storing the full output in a file or other retrievable location.

A useful summary should contain:

• What action was taken.
• What result matters.
• What changed.
• What remains unresolved.
• Where the full output is stored.

The agent can then continue with a smaller active context and retrieve the full material only if necessary.

Strategic context management produces several benefits at once:

• The model can focus on the current task.
• Important instructions are less likely to be buried.
• Fewer tokens are processed repeatedly.
• Compaction occurs later.
• The risk of losing critical information during compression is reduced.
• Tool selection becomes clearer.
• Long-running workflows become easier to maintain.

The cheapest token is often the token that did not need to be loaded. The highest-quality context is not the longest context. It is the context with the best ratio of useful information to total information.

Context is only one part of system cost. Model selection is another.

Using the strongest model for every action can be wasteful. Many tasks do not require frontier-level reasoning.

A simple classification task may only need to place an item into one of several categories. A lightweight model can perform that work.

A research or enrichment task may require more reasoning and justify a mid-tier model.

A difficult architectural decision, routing decision, or high-stakes review may justify the strongest model.

The operating principle is to concentrate expensive intelligence where it creates the most value.

The objective is not to minimize cost at any price. It is also not to maximize quality without regard to cost.

A very cheap model may reduce quality too far. A very expensive model may cost several times more while improving the result only slightly.

The desired point is the combination that provides sufficient quality at a sustainable cost.

This can be visualized as a curve with an optimal region. Moving from a weak model to a capable model can produce a large quality gain. Moving from a capable model to the most expensive model may produce a smaller gain while increasing cost substantially.

Large systems may accept a modest reduction in quality if it produces a much larger reduction in operating cost. The correct trade-off depends on the value and risk of the task.

One routing approach assigns work across three capability tiers.

Approximately 60 percent of usage goes to low-cost models for simple, repetitive, or high-volume tasks.

Approximately 30 percent goes to mid-tier models for work requiring more reasoning, research, or generation.

Approximately 10 percent goes to the strongest models for routing, difficult decisions, integration, and high-value review.

The percentages are an operating pattern rather than a universal law. The principle is hierarchical allocation.

The top-level router should often be highly capable because a routing error can affect every downstream task. The router can then delegate heavy-volume work to cheaper subagents.

Examples include:

• Simple classification -> low-cost model.
• Large research compilation -> mid-tier model.
• Complex design decision -> high-capability model.
• Repetitive extraction -> low-cost model.
• Final quality review -> high-capability model when the output is valuable.

A simplified calculation demonstrates the effect of tiered routing.

If 100 million tokens are processed at $5 per million tokens, the cost is $500.

A tiered allocation uses:

• 10 million tokens at $5 per million.
• 30 million tokens at $3 per million.
• 60 million tokens at $1 per million.

The total is:

• $50 for the high tier.
• $90 for the middle tier.
• $60 for the low tier.

The combined cost is $200.

Compared with $500, the tiered system uses 40 percent of the original cost and saves 60 percent.

The calculation is simplified, but it demonstrates why routing matters. The system avoids paying premium prices for work that does not need premium reasoning.

A lead-processing workflow illustrates model allocation across a business process.

SCRAPING AND EXTRACTION

A low-cost model scans a large number of websites and searches for patterns resembling email addresses or other contact information. The work is high volume and structurally simple.

ENRICHMENT

A stronger model analyzes the business, role, or context associated with the lead. This requires more interpretation.

OUTREACH GENERATION

A mid-tier model produces personalized outreach using a template and the enriched information.

QUALITY REVIEW

A higher-capability model checks a sample or the final outputs for abnormal content, missing information, or obvious mistakes.

The pipeline spends more on the steps where judgment matters and less on the steps dominated by volume.

The cost comparison shows that a mixed-model pipeline can operate at a fraction of the cost of using the strongest model for every stage, while accepting only a limited quality reduction on the simpler work.

Some workloads do not require an immediate response. They can be submitted in bulk and processed later.

Batch processing groups many requests together. The provider can run them during periods of lower system demand. The user accepts a delay in exchange for lower cost.

This is useful for:

• Large-scale classification.
• Bulk extraction.
• Delayed enrichment.
• Non-urgent report generation.
• Processing large lists.

The logic is load balancing. Demand rises and falls during the day. Delay-tolerant work can be shifted to quieter periods rather than competing with immediate interactive requests.

Batching is therefore a time-cost trade-off. It should be used when speed is less important than efficiency.

Parallel agents reduce elapsed time, but they do not eliminate compute cost.

If ten agents perform ten tasks simultaneously, the work may finish much faster than one agent processing the tasks sequentially. The total token usage can still be approximately the sum of all ten agents.

Parallelism should therefore be justified by one or more of the following:

• The time saved has real value.
• The broader search space improves decisions.
• Independent review reduces costly errors.
• The task must meet a deadline.
• The workflow can generate economic value faster than its model cost.

Spawning many agents merely because the platform allows it is not optimization. The number of agents should follow from the goal, the workload, the value of speed, and the definition of done.

The techniques across this module reinforce one another.

A clear definition of done prevents the agent from continuing unnecessarily.

Reverse prompting reduces rework caused by wrong assumptions.

Prompt contracts keep the task aligned as the context grows.

Persistent instructions reduce repeated preference errors.

Skills prevent the agent from reinventing validated workflows.

Multi-agent orchestration assigns work to the appropriate agent.

Stochastic consensus spends extra tokens only when broader search is useful.

Debate spends extra tokens when challenged reasoning has value.

Fresh review spends extra tokens when defects are costly.

Strategic retrieval prevents unnecessary information from filling the context.

Model routing prevents premium models from being used on low-value work.

Batching reduces cost when immediate execution is unnecessary.

These are not isolated techniques. They form a complete operating system for allocating intelligence, information, time, and money.

A mature Agentic AI workflow can be designed in the following stages.

STAGE 1: DEFINE THE OUTCOME

State the high-level goal and the business or practical reason it matters.

STAGE 2: CLARIFY THE REQUEST

Use reverse prompting to expose missing requirements, assumptions, taste choices, decision points, and failure modes.

STAGE 3: CREATE THE CONTRACT

Define the goal, constraints, output format, and failure conditions.

STAGE 4: LOAD ONLY ESSENTIAL CONTEXT

Provide the active rules, relevant project information, and current task material. Keep the larger knowledge base retrievable rather than permanently loaded.

STAGE 5: SELECT THE ARCHITECTURE

Decide whether the task needs one agent, several independent agents, a debate room, specialized workers, browser agents, or a review loop.

STAGE 6: ROUTE BY CAPABILITY AND COST

Assign simple work to low-cost models, moderate work to mid-tier models, and difficult reasoning or high-value review to the strongest models.

STAGE 7: EXECUTE

Let the agents observe, think, and act through their tools.

STAGE 8: MONITOR CONTEXT AND STATE

Store large outputs in files, summarize tool results, maintain shared status, and avoid allowing the conversation to become the only source of project truth.

STAGE 9: VERIFY

Use tests, prompt-contract checks, fresh reviewers, or resolver agents according to the value and risk of the output.

STAGE 10: LEARN

Convert durable corrections into properly scoped rules. Convert successful repeatable procedures into skills.

STAGE 11: OPTIMIZE

Review token usage, model allocation, parallelism, batching opportunities, and whether each component is producing enough value to justify its cost.

A scaled agent system can fail in several predictable ways.

UNCONTROLLED CONTEXT GROWTH

The session contains too many rules, tools, outputs, and historical messages. Quality declines and compaction removes important detail.

POOR RULE SCOPING

A local preference becomes a global rule and damages unrelated work.

SKILL OVERLOAD

Every workflow is loaded in full even when most skills are irrelevant.

ROUTING ERRORS

A weak model receives a task requiring difficult reasoning, or an expensive model receives a simple repetitive task.

UNNECESSARY PARALLELISM

Many agents are spawned without a clear benefit, multiplying cost.

WEAK SYNTHESIS

Independent agents return useful work, but the parent fails to compare or integrate it.

NO FRESH REVIEW

The creator is asked to approve its own work after accumulating a large biased context.

COMPACTION DEPENDENCE

The system assumes automatic compression will preserve every critical detail.

UNCLEAR COMPLETION

Agents continue acting because no definition of done exists.

NO COST VISIBILITY

The architecture is technically successful but economically unsustainable.

Each failure is addressed by one or more of the design patterns in this module.

Mastering Agentic AI means designing the complete system around the model.

The model provides reasoning, but the operating architecture determines whether that reasoning can create consistent value.

A strong system:

• Gives the agent a clear goal.
• Defines done before long execution begins.
• Clarifies ambiguity through reverse prompting.
• Stores durable preferences in persistent instructions.
• Converts recurring procedures into skills.
• Keeps global and local rules separate.
• Provides tools for action.
• Uses retrieval instead of loading everything.
• Routes tasks to suitable models.
• Parallelizes only when speed or coverage justifies the cost.
• Uses independent agents to explore alternatives.
• Uses debate to challenge assumptions.
• Uses fresh reviewers to catch creator bias.
• Uses resolvers and tests to close the verification loop.
• Monitors context and token consumption.
• Uses batch processing when delay is acceptable.
• Learns from corrections without allowing the rule system to become uncontrolled.

The central shift is from prompting a model to managing an intelligent operating system.

The user becomes responsible for goals, constraints, architecture, delegation, and quality standards. The agents perform the iterative observation, reasoning, action, and verification inside that structure.

The strongest system is not the one with the longest prompt, the most expensive model, the largest context window, or the greatest number of agents. It is the system that deliberately allocates context, intelligence, tools, memory, parallelism, and verification according to the value of the task.

Context is finite and must be engineered. System instructions, memory, skills, tools, conversation history, files, and tool results all consume tokens. Long contexts can reduce quality and increase cost. Compaction allows a session to continue but may remove useful detail.

The iceberg technique keeps only essential information immediately available and stores the larger knowledge base below the waterline for retrieval. Selective file reading, targeted search, compact skill metadata, and summarized tool results preserve context without removing access to information.

Model routing controls cost by matching capability to difficulty. A tiered allocation can reserve premium models for routing, difficult reasoning, integration, and high-value review while assigning repetitive work to cheaper models. Batch processing creates additional savings when immediate output is not required.

Agentic scale is an optimization problem. Quality, speed, context, cost, and risk must be managed together. Clear contracts, deliberate retrieval, specialized routing, controlled parallelism, and independent verification create a system that can operate repeatedly and economically.

Conclusion: from Prompting to System Design

Agentic AI begins with the observe-think-act loop, but mastery requires a larger architecture.

The agent needs a clear definition of done. It needs persistent instructions that capture durable preferences. It needs skills that standardize successful workflows. It needs reverse prompting and prompt contracts to remove ambiguity. It needs tools that allow reasoning to become action.

Complex work can be divided among specialized agents. Routers can assign tasks according to model strengths. Video can be converted into executable procedures. Separate browser instances can perform distributed work in parallel. Independent agents can explore a larger search space. Role-based agents can debate. Fresh reviewers can evaluate outputs without inheriting the creator's context.

All of this must operate within finite context and financial limits. Strategic retrieval keeps the active window focused. Model tiers control cost. Batching trades delay for efficiency. Verification ensures that faster or cheaper execution does not become uncontrolled execution.

The practical objective is not autonomy for its own sake. It is reliable goal completion.

A well-designed agent system understands what it is trying to achieve, knows what tools and information are available, chooses the next action, evaluates the result, coordinates other workers when required, learns from durable corrections, verifies important outputs, and stops when the agreed completion conditions have been met.

That is the operating model for mastering Agentic AI.