AI Agent Context Window Management: Implementation Guide [2026]

Emily Winks

Data Governance Expert

Updated:06/17/2026

Published:06/17/2026

23 min read

See Context Eng Studio Live Get the Context Layer Ebook

Key takeaways

Token budget enforcement is the prerequisite — without measured allocations, no technique works reliably.
Static/dynamic separation unlocks prompt caching, cutting costs up to 90% and latency up to 85% on cache hits.
Governance and observability, not technique selection, determine whether your agent stays reliable at week 10.

How do you implement context window management in AI agents?

Implementing context window management requires six sequenced steps: define a token budget before writing any prompts, separate static and dynamic context, select the technique matched to your agent type, enable prompt caching on the static layer, add a context routing layer for dynamic injection, and implement governance and observability. Each step builds on the previous one. Skipping to technique selection without first establishing a budget means building on an unmeasured system.

Key components:

Token budget. Explicit token allocations per context type — system prompt, tool definitions, conversation history, retrieved documents, reasoning — enforced in code before every LLM call
Static/dynamic separation. Static content (system prompt, tool definitions, long-lived knowledge) anchored first; dynamic content (history, retrieved docs, task state) injected last — enables prompt caching
Context routing. A layer that classifies incoming requests and retrieves the right context product per task type, instead of injecting the full knowledge base on every call
Context contract. A human-readable specification defining what information the agent is allowed to receive, what is excluded, how freshness is defined, and who is accountable

Is your data estate AI-agent ready?

Assess Your Readiness

Implementing context window management in AI agents requires six sequenced steps: defining a token budget, separating static and dynamic context, selecting the right technique for your agent type, enabling prompt caching, adding context routing, and establishing governance and observability. According to Zylos AI (2025), 65% of enterprise AI agent failures trace back to context drift and memory loss during multi-step reasoning, not to raw window exhaustion. This guide walks you through the full implementation system, from the token budget you define before writing a single prompt to the governance layer that keeps your agent reliable at week ten, not just week one.

Time to complete: 1–4 weeks depending on agent complexity
Difficulty level: Intermediate to Advanced
Prerequisites: Working LLM API integration, token counting capability, agent framework (LangChain/LangGraph recommended)
Tools covered: tokencap, LangChain ConversationSummaryBufferMemory, Mem0/Zep, Atlan Context Engineering Studio

Why context window management determines whether your agent ships

Most context management failures are not overflow errors. According to Inkeep’s engineering team, nearly 65% of enterprise AI agent failures in 2025 were attributed to context drift or memory loss during multi-step reasoning, not to the underlying model being incapable. A session starting at 2,000 tokens can balloon to 25,000 or more within a few exchanges without active management.

The failure modes are specific. Teams front-load context “just in case,” causing immediate token bloat and diluted signal. They put user queries first, breaking provider-level caching for everything below. They pass full orchestrator context to sub-agents, compounding irrelevance. They set hard rules early in a conversation and watch those rules erode silently as context fills and they drift to the middle of the attention window. According to Redis (2025), accuracy drops 10 to 20 percentage points when relevant information sits in the middle of a long context versus the beginning or end.

The solution is not a bigger context window. Bigger windows scale bad context. The solution is deliberate, sequenced context engineering: knowing what belongs in the window, in what order, and for how long.

This guide is for AI engineers and data engineers building production agents, especially long-running, multi-step, or multi-agent systems. For foundational context on what context window management is and why it matters, start there before following these steps.

Prerequisites

Before you start, verify you have:

Organizational prerequisites:

[ ] A defined agent architecture: single agent, orchestrator with sub-agents, or multi-agent mesh. Implementation choices differ meaningfully across these three patterns.
[ ] Agreed cost and latency targets: context management trades off between these. Know your constraints before selecting techniques.
[ ] A named owner for the “context contract”: someone responsible for defining what the agent knows, when, and why. This matters more than any individual technique.

Technical prerequisites:

[ ] LLM API access: Anthropic Claude, OpenAI GPT-4o, or Gemini (all support prompt caching, critical for Step 4)
[ ] Token counting: tiktoken (OpenAI), Anthropic SDK .count_tokens(), or equivalent
[ ] Agent framework: LangChain/LangGraph for the implementation patterns below; framework-agnostic alternatives noted per step
[ ] External memory for long-running agents: Mem0, Zep, or ChromaDB if building agents with 20+ turn sessions

See LLM context window limitations for background on why these prerequisites matter before the first line of agent code.

Step 1: Define your token budget before writing any prompts

What you’ll accomplish: Explicit token allocations for each context type — system prompt, tool definitions, conversation history, retrieved documents, and reasoning traces — established before a single agent interaction begins. This is the foundation every technique in Steps 2 through 6 builds on.

Time required: 2–4 hours

Why this step matters

Token budget enforcement is not optional infrastructure; it is the prerequisite for everything else. Without it, techniques like sliding windows or hierarchical summarization are applying patches to an unmeasured system. You cannot route context efficiently if you do not know how much space you have to fill.

How to do it

Measure your current system prompt and tool definitions in tokens. Use tiktoken or your SDK’s token counter. Most teams are surprised by how many tokens their tool definitions consume, typically 500 to 2,000 tokens for agents with 5 to 10 tools.
Allocate your model’s context window across five buckets:
- System prompt: 10–15% of total
- Tool definitions: 10–15%
- Conversation history: 25–30%
- Retrieved documents: 25–30%
- Reasoning and output: 20–25%
Enforce limits in code. The tokencap library (https://github.com/pykul/tokencap) provides hard limits with configurable policy: raise an error, compress, or truncate when any bucket exceeds its allocation. Zero infrastructure required.
Run a baseline test. Fire 20 synthetic conversations and log token usage per bucket per exchange. Flag any exchange where a single bucket exceeds its allocation. This baseline becomes your regression benchmark.

Validation checklist

[ ] All five buckets have explicit token limits defined in code
[ ] A token counter runs before every LLM call
[ ] A budget violation handler exists: compress, truncate, or raise an error rather than silently overflow

Common mistakes: Setting the system prompt allocation so tight it cannot contain necessary instructions, then compensating by moving instructions into conversation history (where they are subject to constraint decay, see Pitfall 4). Measure your minimal viable system prompt first, allocate that plus 20% buffer to the system bucket, then distribute the remainder.

Is your enterprise data AI-agent ready?

Most enterprise agents fail because the context they receive is stale, ungoverned, or overly broad. Atlan delivers permissioned, fresh, routed context via MCP, at the scale of your data estate.

Assess Your Readiness

Step 2: Separate static and dynamic context

What you’ll accomplish: A two-layer context architecture: a static layer (system prompt, tool definitions, long-lived knowledge) that rarely changes, and a dynamic layer (conversation history, retrieved documents, task state) that updates every turn.

Time required: 4–8 hours

Why this step matters

Static/dynamic separation is what makes prompt caching work (Step 4). If dynamic content is mixed into the static block, the cache key changes on every call and caching provides no benefit. This separation also prevents constraint decay: hard rules in the static layer are always near the top of the prompt, not buried under turn-by-turn history.

How to do it

Audit every element currently in your context and classify it: static (same across all sessions or sessions of a given type) vs. dynamic (changes per turn, per session, or per user).
Order context with static content first, dynamic content last:
System prompt → tool definitions → static knowledge base → per-session dynamic content → per-turn conversation history → current user input
Build a two-pass assembly pipeline (from Anthropic’s context engineering guidance): Pass 1 loads and validates the static layer. Pass 2 injects dynamic content at request time. These run sequentially so the cache boundary between them is never broken.
Test the boundary. Send ten requests where only the user query changes. Confirm in your API logs that the static block is being served from cache (Anthropic shows cache_read_input_tokens in the response; OpenAI shows cached_tokens).

Validation checklist

[ ] Static elements consistently appear before any dynamic element
[ ] System prompt content is identical across consecutive turns
[ ] Two-pass assembly is implemented and logs show cache hits on the static block

Step 3: Choose and implement the right technique for your agent type

What you’ll accomplish: The right technique from the fourteen available, matched to your specific agent class, rather than a generic list of approaches applied without discrimination.

Time required: 1–2 days

Why this step matters

Technique mismatch is as damaging as no technique. Sliding window truncation applied to a long-running coding agent destroys continuity when early decisions get dropped. Hierarchical summarization applied to a 5-turn support bot adds unnecessary overhead. Match the technique to the agent’s session length and topology.

For a deeper dive into the compress/select/write/isolate framework underlying these choices, see four context engineering strategies.

How to do it: by agent type

Short-lived task agents (under 20 turns):

Sliding window truncation: keep the K most recent messages (K=5 is validated in arXiv research, “Beyond Turn Limits,” arxiv.org/pdf/2510.08276). Simplest approach. Adequate when recency dominates task context.
Progressive context disclosure: load only task-relevant context at session start, not the full knowledge base. Phase 1: minimal system framing. Phase 2: task-relevant retrieval. Phase 3: accumulated state.
Token budget enforcement (Step 1) as the primary safeguard.

Long-running session agents (20+ turns):

Hierarchical summarization: LangChain’s ConversationSummaryBufferMemory maintains recent turns verbatim plus a rolling summary of older exchanges. When oldest messages exceed the buffer, a summarization call merges them into the running summary. This preserves continuity while keeping token count bounded.
Context compaction: when total context nears the limit mid-session (trigger: remaining tokens below 20% of budget), summarize the entire conversation history and restart with the compressed version, preserving critical decisions and discarding redundant tool outputs.
Memory externalization: write information to an external store (Mem0, Zep, key-value store) during the session and retrieve on demand via semantic search. This keeps long-running agents from accumulating unbounded context. For working memory concepts and LLM context, see the companion page.

Multi-agent orchestrator systems:

Context isolation: each sub-agent receives only the task-relevant slice of context, not the orchestrator’s full state. This prevents context inheritance bloat, where sub-agents process irrelevant parent-level state on every call.
Context editing: automatically clear completed tool calls and superseded reasoning between agent handoffs. Anthropic’s native context management includes this mechanism for clearing stale tool call results.
Context routing: each agent type declares what it needs; the routing layer delivers matching context products. This is distinct from RAG injection: routing is about what the agent is allowed to know, not just what is semantically similar.

For the context pruning implementation companion that covers compression in detail, follow that guide alongside this one.

Validation checklist

[ ] Technique selection is documented, with rationale tied to agent session length and topology
[ ] No sub-agent receives its parent orchestrator’s full context
[ ] Long-running agents have a defined compaction trigger
[ ] Memory externalization is in place for any agent expected to run beyond 30 turns

Step 4: Implement prompt caching

What you’ll accomplish: Provider-level caching of your static context layer, achieving up to 90% cost reduction and up to 85% faster first-token latency on cache hits (Anthropic, 2025).

Time required: 2–4 hours

Why this step matters

Prompt caching is the single highest-ROI optimization in context management. A 5,000-token system prompt cached at Anthropic costs roughly 10 cents per 1,000 cache writes and effectively zero for cache reads, compared to full input pricing on every call without caching. For agents with high-volume calls, TrueFoundry’s context engineering research (2025) documents significant latency gains on cache hits.

How to do it

Confirm static content anchors the top of the prompt (Step 2 prerequisite, non-negotiable).
Enable caching at the API level:
- Anthropic (Claude): add cache_control: {"type": "ephemeral"} to the static content blocks in your message array. Cache duration is 5 minutes, refreshed on each cache hit.
- OpenAI (GPT-4o, o-series): automatic for prompts over 1,024 tokens, no code change required. The prefix is cached server-side.
- Gemini: use the CachedContent API to cache system instructions explicitly.
Never put the user query first. This is the single most common caching mistake. The user query changes every call; placing it first means the cache key changes every call, and nothing below it benefits from caching.
Monitor cache hit rate. Target above 80% for static-heavy agents. If hit rate is lower, check whether any dynamic content is bleeding into the static block.

Validation checklist

[ ] cache_read_input_tokens (Anthropic) or cached_tokens (OpenAI) are non-zero in production logs
[ ] Cache hit rate exceeds 80% for agents with significant static content
[ ] Cost per 1,000 calls is measurably lower than the pre-caching baseline

See how Atlan routes context to AI agents

Atlan's Context Engineering Studio lets you build, test, and observe context pipelines before they reach production, with freshness checks, permission filters, and routing built in.

See Context Eng Studio Live

Step 5: Add context routing for dynamic injection

What you’ll accomplish: A routing layer that classifies incoming requests and retrieves the right context product at the right time, instead of injecting the full knowledge base into every prompt.

Time required: 1–3 days

Why this step matters

Context flooding, injecting all potentially relevant information “just in case,” is the proximate cause of context rot. Context rot is not a hard overflow error; it is the gradual accuracy degradation that occurs well before window limits, as low-relevance content dilutes the signal-to-noise ratio. Chroma’s 2025 research on 18 frontier models found that quality drops sharply well before advertised window limits.

The distinction between routing and RAG: RAG retrieves what is semantically similar to the query. Context routing delivers what the agent is authorized and required to know, based on task type, permissions, and freshness, not just semantic similarity.

For a broader view of the context engineering framework that routing operates within, that page covers the full architecture.

How to do it

Classify each incoming task by type: factual lookup, multi-step reasoning, tool use, or conversational. Different types need different context payloads.
Define context products per task type. A factual lookup needs glossary definitions and recent relevant documents. A multi-step reasoning task needs task history, intermediate results, and domain constraints. A tool-use task needs tool output history, current state, and error context.
Build or adopt a retrieval layer. LlamaIndex, a RAG pipeline, or Atlan’s context routing layer can implement this. The key difference from generic RAG: context routing also applies permission filters and freshness checks before injection.
Apply permission filters for enterprise deployments. Agents should only receive context they are authorized to see. Permissioning at the context routing layer, not just at the data layer, prevents data leakage in multi-user or multi-tenant agent deployments.
Validate injection quality. Fire the same task with (a) full knowledge base injection and (b) routed context injection. Measure accuracy and token count. Routed context should hold or improve accuracy while reducing tokens.

Validation checklist

[ ] Different task types receive different context payloads
[ ] Injected context is consistently smaller than the full knowledge base
[ ] Permission filters are applied when the agent operates on enterprise or multi-tenant data
[ ] Freshness timestamps are checked before any retrieved document is injected

Step 6: Implement governance and observability

What you’ll accomplish: The production governance layer that prevents context rot, constraint decay, and context drift, with the observability needed to diagnose failures before they reach users.

Time required: 1–2 weeks for full enterprise deployment; 1–2 days for basic monitoring

Why this step matters

This is the step no competitor guide covers, and the step that determines whether your agent remains reliable at week ten or degrades silently. According to Gartner (2026), 50% of enterprise AI agent deployments are predicted to fail due to insufficient governance. Context governance is what keeps the context contract intact in production.

Constraint decay is the most insidious failure mode: hard rules set early in a conversation (“never output PII,” “always respond in JSON format”) degrade as context fills and those instructions migrate away from the leading edge of the attention window. Most teams notice this only when agents start producing subtly wrong outputs that pass format checks but violate business rules.

How to do it

Add context observability. Log token usage per bucket, per turn, per session. If you have no visibility into what is inside the context window, you are debugging blind. Tools: Atlan Context Engineering Studio, Context Lens (open source), or custom logging middleware.
Store constraints in static context, not conversation history. Any rule the agent must follow unconditionally belongs in the static layer (Step 2), where it is always near the top of the prompt. Rules in conversation history are subject to displacement as context grows.
Implement freshness validation. Before injecting any retrieved document or context product, check its last_modified timestamp. Documents older than your configured threshold, whether 24 hours or 30 days, should be flagged for refresh or excluded from injection.
Write a context contract. A context contract is a human-readable specification: what types of information the agent is allowed to receive, what is explicitly excluded, how freshness is defined, and who is accountable for keeping it current. Assign a named owner. Without this, context management drifts back to “whatever the developer added last sprint.”
Run context quality regression tests on a schedule. Fire a battery of prompts representing each task type. Measure constraint adherence, output format compliance, and accuracy. Run these weekly and treat a regression as a production incident.

Validation checklist

[ ] Token usage per bucket is logged for every production session
[ ] Freshness timestamps are checked before context injection
[ ] A documented context contract exists with a named owner
[ ] At least one automated context quality test suite runs on a weekly cadence
[ ] Constraint decay has been explicitly tested by measuring rule-following at turn 1 vs. turn 30

The context layer your agents are missing

Download the WTF is the Context Layer ebook to understand how governed context delivery separates agents that reason from agents that hallucinate.

Get the Context Layer Ebook

Common implementation pitfalls

The five failure modes below follow predictable patterns. Knowing them before you build is the fastest path to not repeating them.

Pitfall 1: Front-loading context “just in case”

Front-loading is the most prevalent anti-pattern: injecting everything that might be relevant before the agent knows what it needs. According to Redis (2025), accuracy drops 10 to 20 percentage points when key information sits in the middle of a long context versus the beginning or end. The fix is progressive disclosure (Step 3) and context routing (Step 5). The context distraction problem covers this failure mode in depth.

Pitfall 2: Breaking the cache boundary with user-first prompt ordering

Teams naturally write prompts with the user query first. It feels like natural reading order. But placing a changing element first breaks provider-level caching for everything below it, because the cache key is computed from the full prompt prefix. Fix: system prompt first, user query last, always.

Pitfall 3: Context inheritance bloat in multi-agent systems

Orchestrators pass their full context to sub-agents by default in most frameworks. Each sub-agent then processes irrelevant parent-level state on every call, wasting tokens and degrading focus. Fix: context isolation, passing only the task-relevant slice to each sub-agent. A sub-agent should know what it needs for its task, not everything its orchestrator knows.

Pitfall 4: Ignoring constraint decay

Hard rules set early in a conversation erode silently as context fills. The most common example: an agent instructed in turn 1 to “always respond in valid JSON” starts returning natural language by turn 25 because the instruction is now buried in the middle of a long conversation history. Fix: store all critical constraints in the static layer (Step 2), where they remain near the top of the prompt regardless of conversation length.

Pitfall 5: Building without observability

Most context management failures look like “the model did something wrong” until you can see what was actually in the context window. Without token-per-bucket logging, root cause analysis on context failures takes days instead of minutes. Fix: add observability from day one, before you have a production failure to investigate.

Real stories: Context engineering in production

"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."

— Joe DosSantos, VP of Enterprise Data & Analytics, Workday

Watch Now →

"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."

— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey

Watch Now →

Why context window management decides whether your agent ships

The six steps above are not independent optimizations; they form a system. Token budget enforcement (Step 1) gives you the numbers. Static/dynamic separation (Step 2) gives you the structure. Technique selection (Step 3) gives you the right tool for your agent class. Caching (Step 4) gives you the economics. Routing (Step 5) gives you precision. Governance (Step 6) gives you production reliability.

Teams that skip straight to technique selection, picking up sliding windows or hierarchical summarization without first establishing a budget or separating static from dynamic content, build on an unstable foundation. The techniques work, but they work on a system they cannot measure, and they cannot tell when they are degrading.

The Anthropic engineering team articulates this shift: “Context engineering has emerged to describe the practice of intentionally managing what information the model has access to at any moment, how that information is maintained across time and sessions, how it is shared between agents, and what happens when it grows too large to fit in a model’s attention window.” (Anthropic Engineering, 2025)

Bigger context windows do not solve the governance problem; they amplify it. The enterprise teams building reliable agents at Workday and DigiKey are not buying bigger windows. They are governing what enters the window: accurate, permissioned, fresh, and scoped to what each agent actually needs.

That is the difference between an agent that ships and one that hallucinates.

Book a Demo

FAQs about context window management in AI agents

1. What is context window management in AI agents?

Context window management is the practice of intentionally controlling what information an AI agent has access to during inference, including what gets included, in what order, how it is maintained across turns, how it is shared between agents, and what happens when the window approaches its token limit. It is distinct from simply expanding the window size: management is about the quality and structure of what enters the window, not just the quantity.

2. How do you prevent context window overflow in LLM agents?

Prevent overflow by implementing a token budget before the first prompt (Step 1), then applying technique-appropriate controls: sliding window truncation for short-lived agents, hierarchical summarization and context compaction for long-running agents, and context isolation for multi-agent systems. Overflow should trigger a defined handler: compress, truncate, or summarize, not a silent API error. Monitoring token usage per bucket per turn lets you catch budget violations before they become overflow events.

3. What is the difference between a sliding window and hierarchical summarization?

A sliding window keeps the N most recent messages and drops the oldest, with no summarization. It is fast and simple but sacrifices continuity if early context is referenced later. Hierarchical summarization maintains recent turns verbatim plus a rolling summary of older exchanges, preserving key decisions from earlier in the session while keeping total token count bounded. Use sliding window for short-lived agents where recency dominates; use hierarchical summarization for long-running agents where earlier decisions remain relevant.

4. How does prompt caching reduce context costs?

Prompt caching stores the key-value computation for the static portion of your prompt at the provider level, so subsequent requests reusing the same static prefix do not reprocess it. According to Anthropic (2025), this achieves up to 90% cost reduction for the cached portion and up to 85% faster first-token latency on cache hits. The prerequisite is that static content must be consistently anchored at the top of the prompt. Changing elements must come after the cached prefix, never before it.

5. What is context rot and how do you fix it?

Context rot is the gradual accuracy degradation that occurs well before a context window’s hard token limit, as low-relevance content accumulates and dilutes signal quality. Chroma’s 2025 research found this degradation is sharp, not gradual, across 18 frontier models tested. Fix context rot by implementing context routing (Step 5) to prevent undifferentiated injection, enabling context editing to remove stale tool calls, and running context quality regression tests on a schedule to catch degradation early.

6. How do you implement token budget management for an AI agent?

Define five buckets: system prompt, tool definitions, conversation history, retrieved documents, and reasoning/output. Assign a token limit to each as a percentage of your model’s total context window. Enforce limits in code using a token counter that runs before every LLM call. The tokencap library provides hard-limit enforcement with configurable policy. Log actual usage per bucket per turn to build a baseline and detect drift before it causes overflow or accuracy degradation.

7. When should you use RAG instead of expanding the context window?

Use RAG when your knowledge corpus exceeds 50,000 tokens or updates more frequently than a session’s duration. Use long-context injection when the document set is small, stable, and fully relevant to the task. RAG retrieves what is semantically similar; context routing delivers what the agent is authorized and required to know based on task type and permissions. The two approaches are complementary: RAG handles knowledge retrieval, routing handles permission and freshness scoping.

Sources

Share this article

Atlan is the Context Layer for AI — a Leader in the Gartner Magic Quadrant for D&A Governance (2026) and the Forrester Wave for Data Governance (Q3 2025). Atlan unifies your data, business knowledge, and the meaning behind your terms into one Enterprise Data Graph that gives every team and every AI agent the trusted context they need. Trusted by Mastercard, Workday, General Motors, CME Group, HubSpot, FOX, Virgin Media O2, Elastic, and 400+ enterprises representing $10T+ in market cap.

Book a Demo Context Studio Live

AI Agent Context Window Management: Implementation Guide [2026]

Key takeaways

How do you implement context window management in AI agents?

Key components:

Why context window management determines whether your agent ships

Prerequisites

Step 1: Define your token budget before writing any prompts

Why this step matters

How to do it

Validation checklist

Step 2: Separate static and dynamic context

Why this step matters

How to do it

Validation checklist

Step 3: Choose and implement the right technique for your agent type

Why this step matters

How to do it: by agent type

Validation checklist

Step 4: Implement prompt caching

Why this step matters

How to do it

Validation checklist

Step 5: Add context routing for dynamic injection

Why this step matters

How to do it

Validation checklist

Step 6: Implement governance and observability

Why this step matters

How to do it

Validation checklist

Common implementation pitfalls

Pitfall 1: Front-loading context “just in case”

Pitfall 2: Breaking the cache boundary with user-first prompt ordering

Pitfall 3: Context inheritance bloat in multi-agent systems

Pitfall 4: Ignoring constraint decay

Pitfall 5: Building without observability

Real stories: Context engineering in production

Why context window management decides whether your agent ships

FAQs about context window management in AI agents

1. What is context window management in AI agents?

2. How do you prevent context window overflow in LLM agents?

3. What is the difference between a sliding window and hierarchical summarization?

4. How does prompt caching reduce context costs?

5. What is context rot and how do you fix it?

6. How do you implement token budget management for an AI agent?

7. When should you use RAG instead of expanding the context window?

Sources

Context window management: Related reads

Bridge the context gap.Ship AI that works.

Bridge the context gap.
Ship AI that works.