How to Make Cloud 8x Smarter (Anthropic Engineers' Method)

Anthropic engineers merge 8x more code per day than they did a year ago. Nothing about the model, the hardware or the team changed. The only thing that moved is what Claude sees before it starts working.

Save this one.

Your time goes into one of two places. You can pour it into sharper prompts, or into better context. That single choice is where the whole 8x gap comes from.

Anthropic's own research says it plainly: the quality of an agent depends less on the model and more on the context you feed it. Claude only sees what sits inside the context window. Anything outside that window may as well not exist. So the real job of an AI engineer is not clever wording. It is making sure Claude has the right information in front of it before it moves.

That job has a name now. Context engineering. It is taking over from prompt engineering the same way prompt engineering took over from manual scripting a couple of years back.

Why your agent gives bad answers

When an agent fails, the model takes the blame. It edits the wrong file, makes a wrong assumption, ships a mistake any developer would have caught.

The model is rarely the cause. The cause is missing context.

What most people give Claude   |  a prompt
What Claude really needs       |  knowledge, memory, files,
                               |  rules, examples, tools,
                               |  state, previous actions

A prompt is one sentence. Context is the whole information environment Claude works inside. Whether an agent succeeds or fails comes down to what lives in that environment, not which model is running.

Anthropic puts it simply: the model only sees what is in the context window, and context is the operating system for AI. Build it wrong and nothing works, however capable the model is.

What context really is

Context is not just the text you paste before your question. That is one layer. A properly built context has 7 parts working together.

Memory           |  what the agent knows from past sessions
Instructions     |  rules, constraints, coding style
Examples         |  how good output actually looks
Files            |  relevant code, docs, architecture
Previous actions |  what the agent already tried
Tool results     |  what searches and functions returned
State            |  where the task currently stands

Every action Claude takes grows the context. Tool results come back, new files get read, the state updates. Claude reads the new context and picks the next action. That loop, not the prompt and not the model, is how an agent actually runs.

User request
↓
Context built from all seven components
↓
Claude decides action
↓
Tool executes
↓
Result added to context
↓
Claude sees new context
↓
Next action
↓
Repeat until done

A weak agent breaks the loop at step 2. The context is incomplete, so Claude fills the gaps with assumptions, and wrong assumptions produce wrong output. The usual fix is to rewrite the prompt. The fix that works is building the context right.

The 3-layer context stack

Anthropic frames context in 3 layers. Each one has its own job and loads at a different moment in the work.

Global Context   |  always present, every session
Project Context  |  loaded at project start
Task Context     |  loaded for the specific task

Global context is the permanent layer: identity, core rules, coding style, the things the agent must never do. It stays the same across sessions and never needs re-explaining.

Global context contains:
- Agent identity and role
- Coding standards and style rules
- Security constraints
- What to never touch or modify
- How to handle uncertainty

Project context is the knowledge layer: everything Claude needs to understand this codebase. The architecture, the patterns in use, the decisions and the reasons behind them, the things that broke before.

Project context contains:
- README and architecture overview
- AGENTS.md with project-specific rules
- Folder structure and naming conventions
- Testing requirements and patterns
- Key dependencies and why they were chosen

Task context is the execution layer: the file in front of it, the current ticket, the immediate goal, the limits that apply to this exact task.

Task context contains:
- Current file and related files
- The specific goal for this session
- Recent changes and their outcomes
- Current test results
- Constraints specific to this task

Give Claude only task context and it opens every session blind to the global and project layers, guessing at everything it was never told. Those guesses are where the errors come from.

AGENTS.md, the file that changes everything

This is the most important single file in a serious Claude Code setup. AGENTS.md has become the standard for AI coding agents and now sits in thousands of production repos, for one reason: it works.

Project context lives here permanently. Claude reads AGENTS.md at the start of every session and never has to be told any of it again.

# AGENTS.md

## Architecture
Monorepo with Next.js frontend and Express backend.
All API routes live in /api. Never modify /legacy directly.

## Coding Rules
Never use axios. Always use fetch.
Every component: TypeScript, Tailwind, Server Actions.
No default exports except for pages.

## Testing
Vitest for unit tests. Playwright for E2E.
Run npm test before every commit.
Never disable a failing test - fix it or escalate.

## Git
Never commit directly to main.
Always open a PR with a clear description.
Link every PR to a Linear ticket.

## Never Touch
src/payments/ - any change requires human approval
src/auth/tokens/ - security review required
.env files - never read or modify

Every line in that file is one mistake Claude will not repeat. The longer a project runs the sharper AGENTS.md gets, because it collects every error the agent made and every convention the team set.

The context stack that runs serious agents

Strong AI engineers do not open a task by typing a prompt. They load a context stack, a set sequence of information that lands before Claude takes a single action.

Step 1 | load global context - identity, rules, style
Step 2 | load project context - AGENTS.md, architecture, docs
Step 3 | search memory for relevant past experience
Step 4 | load relevant files for this specific task
Step 5 | load current state - test results, recent changes
Step 6 | define task goal with clear success criteria
Step 7 | Claude acts with full information

Here is the default agent next to a context-engineered one:

Bad agent:
Question → Claude → Answer
Claude guesses everything it doesn't know

Good agent:
Question
↓ search docs
↓ search memory
↓ read AGENTS.md
↓ read relevant files
↓ check current state
↓ Claude
↓ Answer built on complete information

The second agent is not smarter. It is better informed. Same model, different context.

Memory, the context that survives between sessions

Anthropic separates the kinds of memory that feed context. Most agents hold only one, the current conversation, which is why they restart from zero every time.

Long-term memory   |  everything learned across all past sessions
Short-term memory  |  what happened earlier in this conversation
Working memory     |  what's in the context window right now

Long-term memory is what makes an agent worth more over time. Every session adds to it, every mistake gets recorded, every pattern that worked gets stored. An agent that has run on a codebase for 6 months knows things about it no prompt can reproduce.

In practice this is a memory file, a markdown doc outside the conversation that the agent reads at the start of a session and updates at the end.

Project Memory

Architecture decisions
- Chose Supabase over Firebase: real-time less critical, SQL queries needed
- Moved from REST to tRPC: type safety across full stack, June 2026

What has worked
- Higher test coverage before refactoring prevents regression
- Breaking large PRs into feature flag releases reduces review time

What has not worked
- Auto-generating migrations: schema drift caused a production incident
- Parallel agent writes to same file: always use worktrees

Recurring patterns
- Auth issues almost always trace back to middleware order
- Performance problems usually start in the database query layer

Read at the start, updated at the end, every session. The agent stops forgetting.

MCP, context from everywhere

Context does not only come from files in the repo. A production agent needs context from every system the team touches: the issue tracker, the error monitor, the docs, the database, the chat.

Model Context Protocol is how Claude pulls that context from outside systems without a custom integration for each one.

Filesystem      |  local files, configs, codebases
GitHub          |  issues, PRs, commit history, CI results
Linear / Jira   |  tickets, priorities, project state
Slack           |  decisions made, context from discussions
Postgres        |  live data, schema, query results
Google Drive    |  docs, specs, meeting notes
Sentry          |  live errors, frequency, affected users

An agent wired up with MCP sees more than the code. It sees the ticket that explains why the feature matters, the Slack thread where the architecture got decided, the Sentry error showing how users hit the bug and the database schema the fix has to respect.

That is full context. Everything Claude needs to decide well without guessing.

What a context-engineered task looks like

Instead of this:

Build the export feature.

You hand Claude this:

Goal
The export feature is blocking free-to-pro conversion.
See signal: /signals/export-too-hidden.md

Relevant files
src/features/export/ - current implementation
src/components/ui/Button.md - button patterns to follow
tests/features/export.test.ts - existing test coverage

Architecture constraints
Read AGENTS.md section: Export Rules
Never modify the billing integration directly

Success criteria
All existing tests pass
New tests cover the three export formats
PR opens with Linear ticket EXP-47 linked
No changes to src/payments/

Same task, different context. The output is not a little better. It is a different kind of output, because Claude is deciding with full information instead of smart guesses.

Build your context stack this weekend

Day 1

Build the three-layer stack. Write a global context file with identity and core rules. Create AGENTS.md with your architecture, coding conventions and never-touch list. Set up a memory file that loads at session start and updates at session end.

Day 2

Connect outside context with MCP. Add the GitHub connector so Claude sees your issues and PR history. Add the filesystem connector so it moves through the codebase fast. Add Slack or Linear if your team decides things there.

Day 3

Test the gap. Run the same task twice, once with your old prompt-only approach and once with the full stack. That gap is where the 8x comes from.

The shift already happened

Prompt engineering was about finding the right words. Context engineering is about building the right information environment.

The strongest engineers at Anthropic do not spend their day polishing prompts. They spend it making sure Claude has the right knowledge, memory, files, rules and state before it acts. The prompt is the last 1% of the work. Context is the other 99%.

Perfect prompts on top of weak context still give you intelligent mistakes. Feed the same model complete context with only average prompts and it makes the right calls. The model does not decide that. The information environment does.

Context is the operating system for AI. Build it right and the 8x stops being an Anthropic story and starts happening in your own codebase.

Save this and give it one weekend.