The Recursive Loop

Most AI deployments follow a straight line. A team builds a system, deploys it, and moves on to the next project. Six months later, the system handles exactly the same scenarios it handled on day one. Same prompts. Same capabilities. Same blind spots. The world around it changed (new customer types appeared, processes evolved, exceptions multiplied) but the system stayed frozen in time.

The Recursive Loop is the alternative. It’s the compounding cycle at the heart of Business-as-Code: BUILD agent systems from schemas and skills, OPERATE them on real work in production, LEARN from the patterns agents discover during operation, BUILD deeper by encoding those learnings as new skills and schema refinements. Then the cycle repeats. Each pass makes the system smarter, the schemas richer, and the skills more precise.

This isn’t training. It’s not fine-tuning. It’s not tweaking prompts. It’s enriching the business context that agents operate on: the structured knowledge that determines what they can handle and how well they handle it.

BUILD → OPERATE → LEARN → BUILD Deeper

The four phases of the loop work like this.

BUILD. Define your business entities as schemas. Encode your domain expertise as skills. Give agents the structured context they need to operate on real work. This is the Business-as-Code foundation: your business translated into machine-readable formats. The first build doesn’t need to be complete. Five entity schemas, ten skills, and enough context for agents to handle your highest-volume workflows. That’s your starting state.

OPERATE. Deploy agents to production. Let them run against real tasks: real customer requests, real procurement decisions, real support escalations. This is where the system meets reality. Agents handle the scenarios your schemas and skills prepared them for. They also encounter scenarios they weren’t prepared for. Both are valuable. Handled scenarios prove the system works. Unhandled scenarios reveal where the system needs to grow.

LEARN. This is the phase most implementations skip, and it’s the one that makes everything else work. During operation, agents surface patterns: requests they couldn’t handle, decisions they were uncertain about, process bottlenecks they observed, edge cases that fell outside existing schemas. These surfaced patterns are raw signal. They represent the gap between what your system knows and what your business needs it to know.

BUILD Deeper. The team reviews surfaced patterns and encodes the high-value ones. A common customer request that agents flagged 50 times becomes a new skill. A recurring entity type that agents couldn’t classify becomes a new schema addition. A decision tree that agents handled inconsistently gets a more precise skill definition. The system didn’t learn in the machine learning sense. It got enriched by humans who reviewed what agents discovered and decided what to encode.

Then you’re back at OPERATE, except now the system handles more scenarios than it did last cycle. That’s the recursion. That’s the compounding. That’s why it works.

Why This Matters

The difference between a static AI deployment and a recursive one is the difference between a tool and an asset.

A static system delivers value on day one and maintains that level indefinitely. Whatever you shipped is what you get. If a new customer segment emerges, someone has to manually update the system. If a process changes, someone has to rewrite the prompts. If an edge case appears, someone has to notice it, diagnose it, and fix it. The system degrades relative to the business it’s supposed to serve because the business keeps moving and the system doesn’t.

A recursive system compounds. Each cycle through the loop adds new knowledge. Week one, your agents handle 20 common scenarios. Week four, they handle 35. Week twelve, they handle 80. The system didn’t get a major upgrade. It got incrementally enriched through dozens of small encoding cycles: a new skill here, a schema refinement there, a process rule clarified. The compounding effect is quiet, but the gap it creates is enormous.

After three months of weekly cycles, a recursive system handles 3-5x more scenarios than the same system at launch. Not because someone rebuilt it. Because the loop ran. Each iteration captured real operational knowledge that the system didn’t have before.

This is Escape Velocity in practice: the point where your AI system is self-sustaining, where the loop generates enough value that the team maintains it as standard practice rather than a special project. The system improves the system. Agents surface what they don’t know, humans encode what matters, agents get smarter, they surface more subtle gaps, humans encode deeper knowledge. The cycle accelerates.

Static AI is a cost center that depreciates. Recursive AI is an asset that appreciates. That’s the difference between “we deployed AI” and “we have a permanent competitive advantage.”

The Mechanics

Here’s how the loop works in practice, week by week.

OPERATE: Agents Run in Production

Agents handle real tasks. They process customer inquiries, route support tickets, draft procurement approvals, generate reports. They make decisions based on the schemas and skills they have. When they encounter a scenario they can handle, they execute. When they encounter a scenario they can’t handle confidently, they flag it.

The key design decision: agents are built to surface uncertainty, not hide it. An agent that encounters a customer type not in its schema doesn’t hallucinate a response. It flags the gap: “Encountered customer with characteristics not matching any defined segment. Classified as ‘mid-market’ by default. Frequency: 12 times this week.”

Surface Patterns

Over a week of operation, agents accumulate a pattern log. This isn’t a bug report. It’s a structured summary of what agents encountered that fell outside their current knowledge. Common categories:

• Unhandled requests. Tasks agents couldn’t complete because no skill existed for that scenario.
• Low-confidence decisions. Tasks agents completed but with uncertainty flags. They used the closest matching skill, but the fit wasn’t clean.
• Frequency anomalies. Scenarios that appeared far more often than expected, suggesting a shift in business conditions.
• Process bottlenecks. Points where agents consistently waited for human input, indicating an encoding gap.

LEARN: The Team Reviews

The team reviews the pattern log weekly. This is a 30-60 minute review, not a multi-day project. The question for each pattern: Is this high-value enough to encode?

Not every pattern warrants encoding. An edge case that appeared once and won’t recur gets noted and dismissed. A new customer request type that appeared 40 times gets fast-tracked. A decision agents handled at 70% confidence gets a refined skill. The team applies judgment: which patterns represent real business knowledge that the system should permanently internalize?

ENCODE: Patterns Become Skills and Schemas

High-value patterns become new Business-as-Code artifacts.

A pattern seen 50 times becomes a skill. If agents flagged “customer requesting bulk pricing outside standard tiers” 50 times in a month, that’s a signal. The team writes a skill that encodes the bulk pricing decision logic: when to apply it, what thresholds matter, what approvals are needed. Next month, agents handle those requests without flagging them.

A new entity type becomes a schema addition. If agents encountered a customer characteristic that doesn’t fit existing segment definitions, the team adds it to the customer schema. Maybe “partner” wasn’t a segment before. Now it is, with its own routing rules and service levels.

A vague skill gets refined. If agents handled a process at low confidence because the existing skill was too general, the team rewrites the skill with more specific conditions, clearer decision trees, and explicit edge case handling.

Cycle time in a healthy implementation: one week. Operate Monday through Thursday. Review Friday. Encode over the weekend or the following Monday. Deploy the enriched system. Repeat.

Self-Proof

NimbleBrain runs The Recursive Loop on its own operations. This isn’t a methodology we advise clients to adopt and then ignore ourselves. It’s how we build, and the results are visible in our own stack.

Our agents operate across our engagement work, handling client onboarding tasks, processing MCP server configurations, managing documentation updates, routing support inquiries. During operation, they surface patterns: a client request type we hadn’t encoded a skill for, a schema gap in our engagement model, a process step that consistently needed human intervention.

Our skills library in packages/skills/ grows through the loop. When agents flag a recurring pattern in how we structure client deliverables, the team encodes a new skill. When we discover that a particular type of MCP server configuration follows a predictable pattern, it becomes a skill. The library started with a handful of core skills. Today it contains dozens, each one the result of an agent surfacing a pattern and a human encoding it.

Our CLAUDE.md files: the literal Business-as-Code artifacts that define how agents operate in our codebase, get refined through the same cycle. An agent hits an ambiguity in a CLAUDE.md? The ambiguity gets resolved. A convention that was implicit becomes explicit. A process that was described in general terms gets specific conditions added. The documentation improves because agents use it and surface where it falls short.

The methodology improves the methodology. That’s the recursive part. Our engagement process gets more refined with each client because agents in previous engagements surfaced patterns that became new skills for subsequent engagements. The system that delivered value to client A is measurably better by the time we engage with client B. Not because we rebuilt it, but because the loop ran.

Getting Started

You don’t need a perfect system to start the loop. You need a deployed system and the discipline to review what it surfaces.

Deploy a basic agent. Five schemas. Ten skills. Enough context for your highest-volume workflow. Don’t wait for complete coverage. The loop exists to fill the gaps that your initial build missed.

Let it run for one week. Agents will handle some scenarios cleanly and flag others. Both outcomes are useful. Clean handling validates your initial encoding. Flags show you exactly where to encode next.

Review the pattern log. Spend 30 minutes on Friday looking at what agents flagged. Pick the top 3 patterns by frequency and impact. These are your encoding targets for the next cycle.

Encode one new skill. Just one. Take the highest-value pattern, write a skill that addresses it, and deploy the updated system. That’s your first cycle. You went from a system that couldn’t handle this scenario to one that can, in one week.

Repeat. The second cycle is easier than the first. The third is easier than the second. Within a month, you’ve encoded a dozen new skills and refined several schemas. The system handles 2-3x more scenarios than at launch. The loop is running.

The common mistake is waiting for readiness. Teams want to encode everything upfront, build the perfect schema library, write complete skills, and then deploy. That approach produces exhaustive artifacts and zero operational feedback. The Recursive Loop works because production exposure is the teacher. Real work surfaces the patterns that matter. Your agents will tell you what they need: you just have to run them and listen.

Context Engineering starts with structure, but it compounds through operation. The first cycle gives you a working system. The tenth cycle gives you a system that knows your business better than any static deployment ever could. That’s not a promise. It’s arithmetic. Each cycle adds knowledge. Knowledge accumulates. Accumulated knowledge compounds. Start the loop.