Context Engineering

You’re deep in an auth system. JWT tokens, session handling, the whole thing. Your AI assistant has full context — architecture decisions, security constraints, the function you half-wrote twenty minutes ago.

Then Slack pings — production bug, payment webhooks are failing.

New conversation, blank slate. You re-explain your codebase from scratch to debug a Stripe signature mismatch. Fix it. Try to go back to auth. The context is gone. Scattered across chat sessions, half-remembered diffs, whatever your brain held onto.

This is the tax. We’ve been paying it so long we stopped noticing.

Complected

Rich Hickey’s concept: complecting. Braiding together things that should be separate. Once complected, hard to reason about, hard to change, hard to even see.

Modern dev workflows are deeply complected.

Git branches mix feature work, bug fixes, and experiments in one tangle. AI conversations reset every session — or sprawl into incoherent mega-threads mixing every concern you’ve touched that week. Your mental model of the project is duct tape and willpower. Your git history interleaves auth commits with payment commits with CSS tweaks until the story is incomprehensible.

We separate concerns in code. Modules, packages, namespaces. Clear boundaries. But the context we work in — the environment we actually sit inside while building — total chaos.

Context as first-class concern

What if you engineered context the way you engineer code?

Not one long conversation. Not one branch with 47 files changed across unrelated systems. Multiple small, clean contexts — one per concern. Each with its own code isolation, its own persistent AI memory, its own docs.

Call each one a strand.

strand new auth-system "JWT authentication"
strand new payment-flow "Stripe webhooks"
strand new ui-redesign "Component library"

Each strand gets a git worktree, a persistent AI context, feature-specific config. Switch to auth-system and your AI remembers your JWT implementation — the architecture, the attempts that didn’t work, the decisions you made last Tuesday. Switch to payment-flow and it knows your webhook handler. No re-explaining. No context bleed.

Same principle that makes modular code attractive. Clear boundaries prevent complexity from cascading.

Forked agents

Here’s where it gets interesting. Each strand’s AI isn’t starting from zero. It’s a fork of a project-level agent.

The base agent knows your stack, your team’s coding standards, your testing patterns. Each strand agent inherits all of that and adds focused domain knowledge.

auth-system agent = project context + deep auth knowledge. payment-flow agent = project context + deep payment knowledge.

Distributed but coherent. Each agent works independently — no coordination overhead — but they share a consistent understanding of the whole. When you change user IDs from integers to UUIDs in the auth strand, the agent flags that payment-flow references user IDs in subscription records. Focused but aware.

Focused but coherent, without the coordination overhead.

Retroactive decomplecting

You’ve been hacking for two hours and realize you’ve got 20 files changed across three unrelated concerns. Happens constantly.

An AI that understands your project can analyze those changes semantically, detect logical boundaries, and split them into clean strands after the fact. Auth changes here, payment fixes there, UI polish separate. Each gets its own clean history.

strand split

# Analyzing 20 changes across 12 files...
# Detected: auth-backend (6 files), payment-fixes (4 files), ui-polish (2 files)
# Create these strands? [Y/n]

Taking a complected mess and decomplecting it into clean contexts. Retroactively. It meets you where you actually are instead of demanding discipline you were never going to have.

What accumulates

The interesting long-term question: what happens when these contexts persist for months?

Your AI conversations become a queryable knowledge base. “How did we decide on this auth approach?” — the answer lives in the strand. New teammates explore strands to understand the codebase. Each strand tells a coherent story: here’s the problem, here’s what we tried, here’s where we landed and why.

The project becomes self-documenting. Not through effort — as a side effect of working in clean contexts.

Decomplecting the whole stack

Hickey’s pattern, all the way down:

• Feature isolation → git worktrees, not overloaded branches
• AI context → persistent per-strand memory, not ephemeral chat
• Mental state → explicit strand contexts, not working-directory roulette
• Documentation → per-strand READMEs, not scattered wiki pages

Each concern gets its own boundary. Each can be understood independently.

We engineer our code. We engineer our infrastructure. We engineer our deployment pipelines. The development context itself — the thing we sit inside while we work — we’ve left to chance.

What happens when we stop doing that?