Part 1 was about teaching Claude Code to remember. Over the 60 days after it, compound learning took over, and what started as a filing system turned into an autonomous development platform.
Install Claude Code, open a terminal, and this is what greets you.
Every session starts from scratch, so you explain who you are and what the project is, you re-state the same constraints Claude violated yesterday, and somewhere around minute 45 the context fills up and you start over.
Here's that fresh install next to the same setup at day 60. The counts in the second column, like every count on this page, are a snapshot from May 2026 when I wrote it, and I've left them the way they were.
Nobody planned a 2.1 GB local intelligence system, least of all me. Each correction, wiki page, and skill came out of a specific session's need, and the five-tier framework from Part 1 gave those decisions somewhere to land.
Claude would make a mistake and I'd correct it, and that correction got saved as a memory file. If the same mistake kept coming back I had Claude write a rule for it, and the rules it still ignored got turned into hooks. Some of those hooks needed real data before they could decide anything, which is how MCP servers came in, and once the servers started overflowing the context window I brought in context-mode to absorb them. Each layer showed up because the one before it wasn't enough by itself.
I'm not a developer, and sixty days of this didn't make me one. I haven't written a line of Python, authored a YAML skill file, or debugged a hook script, and I've never hand-built a skill either. Claude built every piece of the infrastructure (the hooks, the graph indexer, the skills) from my requirements, so what it took from me was knowing what I wanted and being specific about the constraints.
The pace picked up as the layers stacked. The first twenty days were memory and the wiki, basically the filing system, then days 20 to 40 added hooks and MCP servers for enforcement, and days 40 to 60 brought skills, the graph, and context-mode. Each layer made the next one faster to build, so by day 60 Claude could stand up a new skill in about 5 minutes because it already had the patterns from the previous 179.
How it plays out... --set-env-vars wipes all Cloud Run vars → correction → memory → infrastructure rule → PreToolUse hook blocks it from then on
Part 1 had five tiers. By day 60 the system had eleven layers, five of them evolved from the original set and six entirely new.
The overflow layer came out of a limit Part 1 didn't see coming. Part 1 optimized startup, cutting it from 15K to 5K tokens, but the limit I kept hitting came at minute 45, when research filled the window, and context-mode is what made multi-hour sessions possible.
Part 1 described a passive system that stored things and loaded them when they were relevant. What grew out of it acts on its own. It intercepts and enforces without a human in the loop, and it checks its own output before anything ships.
| Part 1 (Passive) | Day 60 (Active) | |
|---|---|---|
| "Hooks auto-suggest wiki pages" | → | Hooks block unsafe operations, validate output, enrich graphs |
| "Memory persists corrections" | → | Memory is entity-linked, graph-indexed, auto-curated |
| "Rules load as standards" | → | Rules enforced by hook chains that gate the action |
| "Wiki pages load on demand" | → | Wiki has inbox, lint, auto-capture, entity extraction |
| "CLAUDE.md routes context" | → | CLAUDE.md is a full orchestration manifest |
| "Contacts live in CRM" | → | Entity pages capture working style, decision patterns, relationship history |
Every passive piece ended up pulling in an active counterpart. Storage got enforcement sitting next to it, reference material got validation, and memory got curation, which looks a lot like the system growing an immune response to the specific ways it kept failing.
Memory holds corrections and the wiki holds knowledge, and for a while nothing held people. Entity pages fill that gap with a structured page per person that compounds across every interaction.
There are two templates, internal and external. The structured top gives you instant prep (role, org position, working style, territory), and an append-only timeline below it grows with every meeting, decision, and collaboration. The pages are seeded programmatically from Slack profiles, then enriched by overnight intelligence crons.
| Without | With entity pages | |
|---|---|---|
| "Who's the AE on that account?" | → | Full org tree with SE/AE assignments in one Read |
| "What did we discuss last time?" | → | Timeline shows every interaction chronologically |
| Meeting prep = 20 min searching | → | One page, auto-routed by SessionStart hook |
By day 60 that was 150+ people mapped across the sales and solutions org trees, each leader sitting there with their reports, Slack IDs, and coverage areas. The CRM has the accounts, and I wanted somewhere that held the humans working them.
Each layer is useful by itself, but most of the payoff came from the places where one hands off to the next, and three loops show it best.
The first one starts with a mistake. Deploy with --set-env-vars instead of --update-env-vars and every env var gets wiped. You correct Claude, the correction lands in memory, that memory gets cited in an infrastructure rule, and from then on a hook blocks any deploy that uses --set-env-vars, so that whole class of error is gone, even in a fresh session with nothing loaded yet.
The second is research turning into routing. When I researched Agentforce Agent Script, Claude wrote it up as a wiki page and the graph pulled the entities out of it, so the next time I mention "agent routing" the SessionStart hook surfaces that page along with the related memories and the architecture doc before I've asked for any of it.
The third is a skill doing the driving. When I run /account-prep the skill already knows the workflow, so it calls the MCP servers for CRM, news, and web, compresses each response through context-mode, and assembles the prep doc under the anti-slop rules and corporate grounding. That's one command driving five systems, and I don't manage any of the context by hand.
If any one of those layers is missing, the loop doesn't close. Memory on its own never blocked that deploy, and the hook only knew the flag was dangerous because memory told it, the same way a skill is stuck with local files until an MCP server gives it outside data.
In Part 1 I cited DDR-001 from the Agentforce Agent Harness and its line "agents forget to remember," and the fix at the time was intrinsic constraint awareness. Two months on, the same failure shows up at every layer of the stack.
| Layer | "Forgetting" Failure Mode | Fix |
|---|---|---|
| Memory | Doesn't check before claiming | Graph recalls relevant memories proactively |
| Rules | Reads but ignores under pressure | PreToolUse hook intercepts before execution |
| Skills | Reinvents instead of loading | Skill routing matches task automatically |
| Wiki | Pattern-matches from training data | ADR hook injects decisions when files in scope |
| MCP | Hallucinates instead of querying | Grounding rules require real data queries |
My 128 memory files never stopped my infrastructure mistakes and three PreToolUse hooks did, which is how I ended up believing every knowledge source needs a matching enforcement mechanism. Knowledge that only sits in context gets quietly skipped once a session gets busy, and the same knowledge sitting behind a hook keeps holding session after session.
When Part 1 went out this all felt like a personal hack, and four weeks after I published it that stopped being true.
Karpathy's "LLM Wiki" hit 5,000+ GitHub stars. The pattern I'd built on, ingest-synthesize-evolve, went viral and spawned a wave of persistent memory tools, and by then I'd been running it in production for months. His own comment on it is the one I keep coming back to.
“I think there is room here for an incredible new product instead of a hacky collection of scripts.”
Andrej Karpathy, on the LLM Wiki pattern
Sixty days after Part 1, my own hacky collection of scripts had become a platform, and I hadn't designed it to. Salesforce's VP-level Futures team published "Not All Agentic Harnesses Are Created Equal" on the exact framework I'd been living in, the scaffolding that gives a model its tools, data, and constraints, which I took as direct validation at the highest level. Anthropic shipped Managed Agents with a memory consolidation feature they called "dreaming," agents consolidating what they learned between sessions, the same pattern as my memory and /curate system, productized by Anthropic themselves.
By May 2026 MCP token overhead was a known problem too. At 58 tools you burn about 55K tokens per turn, and I was already running more than 200 with deferred loading, so for me that one was already solved.
If you're coming from Part 1, this is the order I'd build in, ranked by what paid me back the most.
| # | What | Why | Effort |
|---|---|---|---|
| 1 | One PreToolUse guardrail hook | Prevents your most expensive recurring mistake | 30 min |
| 2 | 3 domain skills | Replaces 30 min of instruction per session each | 2 hrs |
| 3 | One MCP server | Closes the gap between "understands" and "does" | 1 hr |
| 4 | Context overflow management | Removes the 20-minute session ceiling | 1 hr |
| 5 | ADR directory | Reasoning cache that stops re-debating settled decisions | 15 min |
If you only build one thing after Part 1, make it that guardrail hook for your most expensive mistake. Skills were the highest-return investment overall, though. One skill replaces about 30 minutes of manual instruction per session, and by day 60 I had 186 of them, assembled from three suites (project management, Salesforce platform, and developer tooling), plus 28 custom commands I had Claude build for my own SE workflow. I didn't write 186 skills from scratch, I installed the right suites and customized the last mile.
None of this requires 220 memory files or 186 skills. What made the difference for me was getting the first feedback loops running, a guardrail that fires when it matters and a skill that loads expertise automatically, with one MCP server fetching real data, and once those were in place the growth mostly compounded by itself.
Part 1 solved one specific problem, Claude forgetting between sessions. The system that grew out of that fix ended up going after a much bigger one... making a non-developer as productive as a senior engineering team.
My best evidence for that is my own build history. Over 28 days, 199 commits built an AI platform with 6 subagents, 25 data connectors, and production infrastructure, and that was on the early five-tier system. On the day-60 stack the same scope takes less than a week. The models getting smarter doesn't explain that. What kept closing the gap between domain expertise with clear requirements and production software was the local infrastructure around the model compounding, and none of it asked me to be a developer.
The two case studies below come at that from different directions, one about intelligence and one about autonomy.
I shared this article with Gemini Pro and asked it to audit my setup. It came back with 10 confident recommendations, and 9 of them were already solved, six of which are in the table.
| Gemini's Recommendation | Reality |
|---|---|
| "You need a deprecation/garbage collection layer" | Already built. /curate runs weekly with decay rates and prune cycles. |
| "Risk of over-constraint paralysis from hooks" | Claude Code's permission system already has a bypass, so it's not a rigid rule engine. |
| "Graph indexing will cause startup latency" | Already measured at 61ms per file and 151ms at session-init, which is imperceptible. |
| "Users will have dependency conflicts" | The starter kit is a clean template with no machine-specific paths. |
| "You need an auth onboarding wizard" | Recipients are Salesforce employees with sf CLI already authenticated. |
| "Risk of identity/state bleed in the repo" | The starter kit is scrubbed of customer data, personal paths and IDs. |
It was well-structured advice that would have been right for a generic setup and was wrong for mine, and it couldn't have known that because it had no context about me.
It was the same model family with the same parameters, and the only thing missing was what my system remembers about my specific situation, and that's the difference between the audit it gave me and a useful one.
The first case study is about context making AI smarter. This one goes a step further, to the point where context makes it autonomous and it operates on its own for a whole night.
I had a 7-pillar architecture plan for transforming a production intelligence platform, hardened through three rounds of architectural audit that produced 14 accepted fixes and 6 rejected findings, each with documented rationale. I approved it at 10 PM, told Claude "Build overnight. Don't stop." and went to sleep.
| Phase | Original Estimate | Actual |
|---|---|---|
| Salesforce metadata (object + 12 fields + event + service + tests) | 3-4 days | ~2 hours |
| Pipeline infrastructure (types, extractor, evaluator, connector) | 3-4 days | ~1.5 hours |
| Three API endpoints (competitive, risk, temporal) | 2-3 days | ~45 minutes |
| Brand design system provider | 3-4 days | ~30 minutes |
| Conversational Agent Router | 4-5 days | ~30 minutes |
| Total (4 phases) | 15-20 days | ~5 hours |
Any frontier model can generate files quickly, but getting 19 of them to land as one coherent system, with the pieces actually fitting together, came from the operating system underneath it.
| OS Layer | What It Contributed |
|---|---|
| Memory | Knew the entire architecture, 196 cached accounts, data model history, and deployment patterns, so there was no re-briefing |
| Rules | Security governance, architecture patterns, and voice standards, enforced automatically on every file written |
| Plan | 3-round audited plan with explicit file paths, interface contracts, and a dependency graph, which left zero ambiguity |
| Wiki | 60+ pages of project knowledge, integration topology, and platform constraints that answered questions without asking me |
| Hooks | Metadata validators scored every file (90-120/120) and caught issues at write-time, before anything reached a deploy |
| Role | Time |
|---|---|
| Approve the plan (after 3 audit rounds) | 30 min |
| Say "build overnight" | 5 seconds |
| Sleep | 8 hours |
| Verify build + tests + deploy next morning | 10 min |
| Total human involvement | ~45 minutes |
My role moved from writing code to approving plans and verifying outcomes, about 45 minutes of it, and the context architecture carried the independent execution in between. I care about that more than the 25x number.
It took me 60 days of trial and error to get here, and the architecture's scaffolding is packaged as a kit in two editions, an internal one for Salesforce employees and a provider-agnostic public one for everyone else. Both carry rules, hooks, skills, a voice checker and overnight scripts. You clone the repo, run setup, and start with the structure. The memories, the entity graph, most of my harness code and my MCP server stay with me.
The architecture, templates, and feedback loops all transfer. The 220+ specific memories don't, because those are my corrections and my project state and yours will look different, so the kit hands you the scaffolding and compound learning fills it in over time.
Layer 1, the identity skeleton, is a template CLAUDE.md with the routing-table structure, role definition, project registry, and essential standards baked in (anti-slop, anti-hallucination), plus a pre-wired wiki index. Filling in your own role, projects, and constraints takes about 10 minutes.
For rules and guardrails (layer 2), the Salesforce edition ships 17 rules, covering communication, security, architecture, the Salesforce platform and its style guide, testing, LWC and SLDS 2, Agent Script, agent security, model selection, the four proof-family rules, and structural voice. It also ships seven wired hooks (context routing on start, a guardrail for destructive commands, a product-name check, a SOQL schema check, two writing-quality gates, and a gate that wants proof before you call something deployed) plus four opt-in. The public edition keeps the generic rules and hooks and leaves the Salesforce ones out.
Then there's the SE skill pack, 31 skills in the Salesforce edition, five of them the core SE workflows that each replace about 30 minutes of manual instruction per use: /account-prep for pre-meeting intelligence, /deal-strategy for competitive positioning and a talk track, /email-draft for anti-slop customer email, /post-meeting for capture, CRM, and follow-up, and /demo-prep for a script built from a brief.
The fourth layer is intelligence automation, a 15-row Slack channel roster template, overnight scripts that scan Exa, Hacker News, and GitHub, and a digest script that synthesizes them into your wiki inbox. There's a reference MCP config in there too, with Salesforce Docs and the SE grounding service, and you request the grounding token separately. Replace the example roster rows with your own OU channels.
Last come the entity pages, a wiki/people/ directory with the two templates, internal and external. You seed your org tree from Slack profiles, with Claude pulling name, title, email, and timezone programmatically, and each page puts org position at the top with an append-only timeline below it. After one session every leader and their reports are mapped, and after a month you've got a relationship graph no CRM captures.
| Category | Channels | What You Get |
|---|---|---|
| Competitive Intel | Your team’s solutions channel, an analyst-coverage channel | CI drops, IDC/ISG/Gartner reports |
| Product & Roadmap | Product-update and release channels | What shipped, what's GA, deprecations |
| AI & Tooling | Internal AI and engineering-productivity channels | Internal AI tools, techniques, launches |
| SE Enablement | Enablement and demo-sharing channels | New assets, techniques that work |
| Territory | Your business unit’s broadcast channels | OU updates, leadership priorities |
| Industry | One channel per industry you cover | Vertical trends, reference stories |
You don't need to code any of it. Tell Claude what you want enforced, what workflow you need automated, and which mistake it should never make again, and it'll build the hooks, write the skills, and configure the MCP servers itself. Your part is direction and domain expertise, the same skills that make you good at the job you already have.
Get the kit: Salesforce employees clone the internal edition, git clone https://git.soma.salesforce.com/jtehrani/claude-code-se-starter-kit.git && cd claude-code-se-starter-kit && ./setup.sh. Everyone else gets the public edition, git clone https://github.com/jtehrani84/context-engineering.git && cd context-engineering && ./setup.sh. If the clone is refused, contact John Tehrani (jtehrani@salesforce.com) for access.