How Upjack Powers NimbleBrain Engagements

Every NimbleBrain engagement delivers a running AI system in 4 weeks. A production application (no prototype phase, no proof of concept) the client owns, operates, and extends independently. Upjack is the reason that timeline is possible.

The declarative architecture converts domain analysis into working software faster than any code-first approach. Schemas defined during week one ARE the data model. Skills written during week two ARE the behavioral logic. MCP servers connected during week three ARE the integration layer. There is no translation step between discovery and delivery. The Business-as-Code artifacts that capture the client’s domain knowledge are the Upjack application itself.

This is how it works, week by week.

Week 1: Domain Observation and Schema Definition

The engagement starts with The Embed Model: a senior NimbleBrain operator embeds directly with the client’s team. Not in a conference room reviewing slide decks. In the actual operating environment, observing how work happens.

The operator shadows the people who do the work. Customer service reps handling escalations. Operations managers allocating resources. Sales engineers scoping deals. The goal is to identify three things: the entities that matter (what nouns does the business operate on?), the processes that consume time (what decisions repeat daily?), and the knowledge that lives in people’s heads (what does the ten-year veteran know that the new hire doesn’t?).

Each observation converts directly into Upjack artifacts. The entities become JSON schemas: Customer, Order, Escalation, Resource, Deal. Fields, valid states, relationships, and constraints are defined with precision. If the business has four customer tiers, the schema has a four-value enum. If orders can be in seven states, the schema encodes seven valid transitions.

By the end of week one, the engagement has 10-20 entity schemas that formally define the client’s domain. These schemas are readable by anyone in the organization. The VP of Operations can open the Customer schema and verify: yes, these are the fields that matter, these are the valid states, these relationships are correct. Validation happens in hours, not weeks, because the artifacts are human-readable.

This is Business-as-Code as a delivery methodology. The same artifacts that document the domain ARE the application’s data model. No requirements document that an engineer translates into code. No specification that drifts from the implementation. The schema IS the spec, and the spec IS the running system.

Week 2: Skill Writing and Initial Application

With schemas defined, week two focuses on encoding domain expertise as skills, Skills-as-Documents in production.

The NimbleBrain operator interviews domain experts and writes skills collaboratively. A customer success manager describes their escalation process. That description becomes skills/route-escalation.md: trigger conditions, decision criteria, routing logic, exceptions, expected outputs. All in markdown. All in the expert’s language.

The key accelerator: domain experts validate skills immediately because skills are written in natural language. The customer success manager reads route-escalation.md and says “that’s right, but you missed the exception for enterprise accounts,” and the operator adds two lines to the skill file. The iteration cycle is minutes, not sprint cycles. No engineer needs to interpret the feedback and translate it into code.

By mid-week, the first skills are running inside the Upjack application. The agent reads the schemas, follows the skills, and produces decisions. The team tests against real scenarios: “This escalation should have gone to the enterprise queue.” “This deal should have been flagged for review.” Each test either confirms the skill or reveals a gap. Gaps get fixed in the skill file, immediately.

The typical engagement produces 15-30 skills during week two. Each skill captures a specific process or decision that previously required expert judgment. The skills compound with the schemas. The agent that knows what a customer IS (schema) and knows how to route an escalation (skill) starts making decisions that match expert judgment.

Week 3: MCP Connections and Integration

Week three connects the Upjack application to the client’s actual systems. The app knows the domain (schemas) and the processes (skills). Now it needs tools to act.

MCP server connections are the integration layer. Each connection gives the agent access to an external system: CRM for customer data, ERP for operations, email for communications, databases for operational queries, notification systems for alerts. NimbleBrain maintains 21+ open-source MCP servers at mpak.dev, and builds custom servers when a client system requires one.

The standardized connection model accelerates integration. Connecting to Salesforce doesn’t require building a custom API integration. It requires installing the Salesforce MCP server and adding one line to the manifest. The agent gains access to customer records, deal data, and activity logs, all through a standard protocol.

Three to five MCP server connections is typical for a first engagement. The most common pattern: one connection to the primary data source (CRM, ERP, or database), one to the communication layer (email or Slack), and one to the operational system the app automates (project management, ticketing, or workflow tools).

Each connection is tested against real data. The agent reads actual customer records, processes them through the skills, and produces outputs that the team evaluates. This is production testing, not demo testing. Real data, real edge cases, real exceptions.

Week 4: Governance, Testing, and Handoff

Week four is about confidence and independence.

Governance rules get encoded as context files and skill constraints. Which decisions require human approval? What are the failure modes? When should the agent escalate instead of act? These guardrails are written in the same human-readable format as everything else, so the compliance team can review them directly.

The testing protocol uses real operational scenarios from the client’s recent history. Take the last 100 customer escalations. Run them through the Upjack app. Compare agent decisions with expert decisions. The alignment rate on a well-tuned engagement is typically above 85% by end of week four, with the remaining cases being genuine edge cases that benefit from human review.

Then the handoff. The client receives everything: schemas, skills, context files, manifest, MCP server configurations. All in their git repository. All version-controlled. All readable by their team.

This is Escape Velocity, the point where the client operates the system independently. It works because Upjack’s declarative architecture means the client doesn’t need engineers to maintain or extend the application. Domain experts modify skills when processes change. Data architects adjust schemas when the domain evolves. Operations teams add context as new rules emerge. The system grows with the organization.

Proof Patterns: What Gets Built

Three real engagement patterns that show Upjack in production.

Customer Operations Automation

A services company with a 12-person customer success team spending 4+ hours daily on manual account reviews, escalation routing, and status reporting. The account review process lived entirely in the heads of two senior CSMs.

Upjack app delivered: 8 entity schemas (Account, Contact, Escalation, Health_Score, Playbook, Task, SLA, Intervention), 22 skills covering the full account lifecycle, 3 MCP connections (CRM, ticketing system, Slack). The agent now handles account health scoring, escalation routing, and daily status reports. The senior CSMs review and override when needed; they spend time on judgment calls, not data collection.

Time from kickoff to production: 4 weeks. Daily manual review time dropped from 4.2 hours to 45 minutes. The team modified 6 skills in the first month after handoff, process refinements they made themselves, in markdown, without engineering support.

Sales Process Intelligence

A B2B company where deal qualification depended on one sales director’s pattern recognition. When she was on vacation, deals stalled or got misqualified. The qualification criteria existed nowhere in writing.

Upjack app delivered: 5 entity schemas (Lead, Opportunity, Account, Product_Fit, Competitor), 14 skills covering qualification, scoring, next-best-action, and competitive positioning, 2 MCP connections (CRM, email). The agent scores inbound leads against the criteria the sales director encoded as skills, recommends next actions, and flags deals that need her direct attention.

Time from kickoff to production: 3 weeks (smaller scope). The sales director spent two days writing skills with the NimbleBrain operator. She said it was “the first time anyone actually wrote down how I evaluate deals.” Six months after handoff, the team had added 4 new skills and modified 8 others. The system evolved with their playbook.

Compliance Monitoring

A financial services firm with a compliance review process that required senior analysts to manually check transactions against 40+ regulatory rules. Reviews took 3 days per batch. Backlogs grew every quarter.

Upjack app delivered: 6 entity schemas (Transaction, Account, Rule, Alert, Review, Exception), 18 skills covering rule application, exception detection, alert prioritization, and report generation, 4 MCP connections (transaction database, compliance database, document storage, notification system). The agent applies rules to transaction batches, flags exceptions, prioritizes alerts by severity, and generates review-ready reports.

Time from kickoff to production: 4 weeks. Batch review time dropped from 3 days to 4 hours. The compliance team added 12 new rules as skills in the first quarter. Regulatory changes that previously required weeks of engineering to implement now took an afternoon of skill writing.

Why Declarative Delivery Works

The common thread across every engagement: the declarative architecture compresses the timeline between understanding a domain and having a running system.

In a code-first approach, discovery produces requirements. Requirements get translated into code. Code gets reviewed, tested, deployed. Each translation step introduces delay and distortion. The domain expert says “we check these five things.” The engineer interprets that as code. The code doesn’t quite match the intent. The expert reviews, gives feedback. Another sprint. The feedback loop is measured in weeks.

In Upjack, the discovery artifacts ARE the running system. The domain expert says “we check these five things.” Those five things become a skill file. The skill runs immediately. The expert reviews the output against their judgment. Gaps get fixed in the skill: a line added, a condition clarified. The feedback loop is measured in minutes.

That compression is why 4-week delivery works. Not because we cut corners. Because the declarative model eliminates the translation steps that consume 80% of traditional project timelines.

And it’s why handoff works. When NimbleBrain exits, the client isn’t left with a codebase they can’t read. They have schemas in JSON, skills in markdown, context in plain text, and a manifest that ties it together. Their domain experts maintain it. Their compliance team reviews it. Their operations team extends it. The system belongs to the people who understand the business, which is exactly where it should be.

For a technical introduction to Upjack’s architecture, see What Is Upjack. To build your first app yourself, see Building Your First Upjack App in 30 Minutes.