The Independence Kit: What We Leave Behind

The Independence Kit is what NimbleBrain delivers at the end of every engagement. Skip the slide deck, the summary report, the link to a vendor platform you’ll rent forever. A complete, self-contained package of production systems, documented knowledge, and operational capability. Everything your team needs to keep running, update, and grow without us.

Eight components. Each one exists because without it, independence breaks down at a specific point. Remove any one, and your team hits a wall within 90 days.

1. Production-Deployed System

The first component is the most obvious and the most overlooked. The system is live. Running. In production. Processing real data through real integrations, producing real outputs that real people use.

This is not a repository of code your team needs to deploy. Not a configuration guide they need to follow. Not a staging environment that “just needs to be promoted.” The system is already running in your infrastructure, connected to your tools, monitored by your dashboards. Your team’s first post-engagement experience is operating a live system, not spending three weeks trying to get the handoff code to work.

Teams that receive code they’ve never seen running lose confidence immediately. The first deployment failure (and there’s always a first deployment failure) creates doubt about everything the consultancy delivered. A production-deployed system eliminates that gap. The team starts from a position of “this works and I can see it working” rather than “I hope I can get this to work.”

The Embed Model makes this possible. Because NimbleBrain builds inside your infrastructure from day one, there is no handoff deployment. The system has been running in your environment for weeks by the time the engagement ends. It’s been tested against your data, your integrations, your edge cases. The production deployment isn’t a final deliverable. It’s the environment the team has been watching operate for the past four weeks.

2. Business-as-Code Artifacts

The complete library of schemas, skills, and context documents created during the engagement. These are the machine-readable definitions of your business, the knowledge layer that makes AI agents effective on your specific operations.

Schemas define your business entities in JSON. Customer types, product tiers, order states, approval hierarchies, compliance categories. Each schema specifies exactly what fields an entity has, what values are valid, what relationships exist. These aren’t documentation. They’re executable definitions. When an agent validates a customer record against the customer schema, it’s using the same artifact your team reads to understand the data model.

Skills encode your domain expertise in structured natural language. A pricing skill describes when discounts apply, what thresholds trigger manager approval, how multi-year contracts get handled differently from annual ones. A routing skill describes which team handles which request types, what context to include in the handoff, what SLAs apply. Skills are written with explicit conditions, branches, and exceptions, precise enough for machines to follow, readable enough for domain experts to verify and update.

Context provides the organizational knowledge that ties schemas and skills together. Industry terminology. Departmental relationships. Historical decisions and their reasoning. Vendor quirks. The unwritten rules that experienced employees carry in their heads. Context is what turns mechanical rule-following into informed decision-making.

Business-as-Code artifacts serve double duty here. For agents, they’re operating instructions. For your human team, they’re the most precise business documentation the organization has ever produced. When a process changes, your team updates the artifact, and both the agent and the documentation stay in sync. No separate documentation to maintain. No drift between how the system works and how the docs say it works.

3. MCP Server Configurations

Every external integration built during the engagement is delivered as a standalone MCPB bundle: versioned, packaged, independently deployable. The CRM connection. The ERP integration. The email system. The database queries. The project management tool. Each one is a discrete package with its own documentation.

For each MCP server, the kit includes: what system it connects to, what tools it exposes to agents, what environment variables it requires, what authentication method it uses, what rate limits apply, what error states it can produce, and what to do when those errors occur.

Integrations are the most common point of failure in production AI systems, so this component matters more than it looks. APIs change. Credentials expire. Rate limits get hit. Endpoints move. When a connection breaks, your team needs to know exactly which MCP server is affected, what it’s supposed to do, and how to fix or replace it. The MCP servers follow the open MCP protocol, documented in the mpak registry. Your team isn’t stuck with NimbleBrain-specific tooling. Any developer who can manage a Node.js or Python package can manage an MCP server.

4. Architecture Decision Records

Not just what was built, but why it was built that way. Every significant architectural choice during the engagement is captured in a structured decision record: the context that prompted the decision, the options considered, the option chosen, and the reasoning behind the choice.

Why did the customer schema use nested segments instead of flat categories? Because the client’s enterprise accounts have sub-divisions that need independent routing. Why does the escalation skill route to a human for amounts over $25,000? Because the compliance team requires manual review above that threshold and automating it would create regulatory risk. Why is the inventory MCP server configured with a 30-second timeout instead of the default 10? Because the ERP system takes 15-20 seconds to respond during batch processing windows.

Without this, decisions become invisible constraints. Six months from now, someone on your team will look at a configuration choice and wonder “why is this like this?” Without the decision record, they have two options: leave it alone (even if it no longer makes sense) or change it (risking something they don’t understand). With the decision record, they can evaluate whether the original reasoning still holds and make an informed choice about whether to change it.

5. Operational Runbooks

Step-by-step procedures for the tasks your team will actually perform. Not a theoretical operations manual. Not a complete reference document. Practical, tested playbooks for daily operations and common maintenance.

The runbooks cover: how to update a skill when a business process changes. How to add a new entity to a schema. How to deploy a modified MCP server. How to check why an agent produced wrong output. How to add monitoring for a new automation. How to roll back a change that caused problems. How to onboard a new team member to the system.

Each runbook follows the same structure: when to use it, what you need before starting, step-by-step instructions, how to verify the change worked, and what to do if something goes wrong. No ambiguity. No assumed knowledge.

Runbooks bridge the gap between “knowing the system exists” and “knowing how to operate the system.” Your team might understand the architecture, read the Business-as-Code artifacts, and see the monitoring dashboards. But when an alert fires at 3 PM on a Tuesday and the senior engineer is on vacation, the person responding needs a step-by-step procedure, not conceptual understanding.

Every runbook in the Independence Kit was used during the engagement. Your team followed the procedures while NimbleBrain was still present. Gaps were caught and filled in real time. By the time we leave, these aren’t reference materials. They’re practiced workflows.

6. Monitoring and Alerting

Dashboards showing system health, agent performance, error rates, and cost tracking. Alert thresholds configured for your specific system, not defaults, not generic recommendations. Thresholds tuned during four weeks of production operation to distinguish between noise and signal.

The monitoring covers: agent task completion rates by type, MCP server response times and error rates, schema validation failures, skill confidence scores, escalation frequency, and infrastructure resource utilization. Each metric has a defined “healthy” range and an alert threshold.

Monitoring is how your team knows the system is working without manually checking every output. It’s also how they catch degradation before users report it. A skill confidence score dropping from 92% to 74% over two weeks means something changed in the business environment that the skill doesn’t account for. Catching it through monitoring means the team updates the skill proactively. Missing it means agents produce increasingly wrong outputs until someone complains.

7. Troubleshooting Guide

The 10 most likely failure scenarios, documented in detail: what the symptom looks like, what to check first, what to check second, how to identify the root cause, and how to fix it.

These aren’t hypothetical scenarios. They’re drawn from the failure patterns observed during the engagement and from NimbleBrain’s experience across dozens of production AI deployments. The scenarios include: agent producing incorrect classifications (check the schema), agent applying the wrong skill (check skill conditions and context), MCP server connection failures (check credentials, endpoints, rate limits), unexpected escalation spikes (check for business process changes not yet encoded), slow agent response times (check MCP server latency and context size), schema validation errors on new data (check data quality and schema completeness), skill confidence drops (check for domain drift), deployment failures after artifact updates (check version compatibility), and monitoring alert fatigue (adjust thresholds).

The first time something goes wrong after the engagement ends is the critical test. If the team can diagnose and fix it using the troubleshooting guide, confidence solidifies. If they can’t, doubt creeps in: about the system, about their ability to manage it, about whether they should call for help. A specific, tested troubleshooting guide turns the first failure from a crisis into a routine resolution.

8. Training Session Recording

A 2-3 hour recorded walkthrough of the entire system. Not a generic “how AI works” presentation. A specific tour of your deployment: your schemas, your skills, your MCP servers, your monitoring dashboards, your runbooks, your deployment pipeline.

The session covers: system architecture and how components interact, how to navigate the Business-as-Code artifacts, how to make common changes (update a skill, add a schema field, deploy an MCP server update), how to read the monitoring dashboards, how to use the troubleshooting guide, and a Q&A section addressing the team’s specific concerns.

The recording serves two audiences. For the team that was present during the engagement, it’s a reference, a way to revisit a procedure they watched but didn’t internalize. For future team members who join after the engagement, it’s an onboarding tool. A new engineer can watch the recording, read the Business-as-Code artifacts, and understand the system in a day. Without it, onboarding depends on someone from the original team having time to explain everything. Tribal knowledge, reintroduced through the back door.

The Standard: Self-Sufficient Without Us

Every component of the Independence Kit passes one test: if NimbleBrain disappeared tomorrow, could a competent engineering team pick this up and operate it?

No component references NimbleBrain systems. No component requires NimbleBrain credentials. No component assumes NimbleBrain availability. The kit is self-contained, self-documented, and self-sufficient. It lives in your repository, under your version control, owned by your organization.

That’s the standard. Not “everything you need to operate with our support.” Everything you need to operate, period. The Independence Kit is not a courtesy. It’s the deliverable. It’s the reason the engagement exists: to produce an organization that doesn’t need another engagement.