Business-as-Code for Non-Technical Leaders

You keep hearing about Business-as-Code. Your engineering team is talking about it. Your AI vendor mentioned it. Someone sent you an article. And every explanation leads with JSON, schemas, markdown, and terms that assume you write code.

You don’t write code. You run a business. This page is for you.

The 30-Second Version

Business-as-Code is a way to write down how your business works, in enough detail and structure that AI agents can read it and act on it. Not vaguely. Not “here’s a summary of our company.” Precisely: these are our customer types, these are the rules for handling each one, these are the exceptions, here’s what to escalate to a human.

You already know all of this. It’s in your head. It’s in your best people’s heads. Business-as-Code gets it out of heads and into files that both humans and AI can read.

What Schemas Actually Are

Forget the word “JSON.” A schema is a structured form that describes a business entity.

You know what a customer record looks like in your CRM. It has fields: name, company, industry, deal size, lifecycle stage, communication preferences. Some fields are required. Some have specific valid values (lifecycle stage can only be “prospect,” “active,” “churned,” not “kind of active” or “maybe churned”).

A schema is exactly that: a formal description of what fields an entity has, what values are valid, and how entities relate to each other. Here’s what one looks like in plain language:

Customer schema:

• Name (required, text)
• Company (required, text)
• Segment: one of “enterprise,” “mid-market,” or “startup” (required)
• Lifecycle stage: one of “prospect,” “qualified,” “active,” “at-risk,” “churned” (required)
• SLA tier: “premium” if enterprise, “standard” if mid-market, “basic” if startup
• Primary contact email (required)
• Annual contract value (number, required if lifecycle is “active”)
• Renewal date (date, required if lifecycle is “active”)

That’s a schema. Engineers write it in JSON format so computers can read it precisely. But the content (the fields, the rules, the valid values) comes from you. You’re the one who knows that customer segments drive SLA tiers. You’re the one who knows renewal dates matter. The engineer just structures what you already know.

What Skills Actually Are

A skill is a decision checklist for a specific business process, written in enough detail that someone (or something) with no prior knowledge of your business could follow it.

Think about how you’d train a sharp new hire on lead qualification. You wouldn’t hand them a paragraph and say “figure it out.” You’d walk them through the logic:

Lead qualification skill:

• When a new lead comes in, check the company size. Over 500 employees? Enterprise segment. 50-500? Mid-market. Under 50? Startup.
• Check the industry. If it’s financial services or healthcare, flag for compliance review before proceeding.
• Check the lead source. Inbound demo request? High intent; route to sales within 4 hours. Downloaded a whitepaper? Medium intent; add to nurture sequence. Referred by existing customer? High intent regardless of other signals; route to sales immediately.
• If the annual deal value estimate exceeds $100K, assign a senior account executive. Under $100K, assign the standard team.
• Exception: if the lead mentions a competitor by name in the inquiry, flag for competitive response playbook regardless of other criteria.

That’s a skill. It’s the decision logic that lives in a senior sales manager’s head, written down step by step. The format is structured markdown: headers, bullet points, clear conditions and actions. No code required.

AI agents read this skill and follow it. When a new lead comes in, the agent checks company size, checks industry, checks lead source, applies the routing rules, and handles the exceptions. It does what your best sales manager does, but it does it consistently, every time, at any scale.

What Context Is

Context is the background information that makes schemas and skills work together intelligently.

Schemas tell an agent what your entities look like. Skills tell an agent how to make decisions. Context tells an agent why certain decisions matter more than others right now.

Context examples:

• “We’re a B2B SaaS company. Customer retention is existential. Every churned enterprise account costs us $180K ARR. Prioritize retention signals over new acquisition.”
• “Q4 is our biggest quarter. From October through December, approve discount requests up to 15% without VP approval. Rest of year, cap at 10%.”
• “We’re expanding into healthcare. All leads from healthcare companies need compliance review. This is new; our standard process doesn’t include this yet.”

Context is the strategic and situational knowledge that changes how agents apply the schemas and skills. Without it, an agent follows the rules mechanically. With it, the agent follows the rules with judgment appropriate to your current business situation.

Your Role: Domain Expert, Not Engineer

Here’s the part that matters most for you. In a Business-as-Code implementation, there are two distinct roles:

Domain experts (you) define what the business does. You know the customer segments, the decision rules, the exceptions, the edge cases, the “it depends” logic that no one has written down. You articulate this knowledge in conversations, in reviews, in working sessions with the engineering team.

Engineers structure what you define. They take your knowledge and encode it into schemas (JSON format), skills (structured markdown), and context (organized files). They handle the syntax, the file formats, and the technical infrastructure.

Your job is not to learn JSON. Your job is to answer questions like:

• What are the customer types, and how do they differ?
• What triggers an escalation? What are the thresholds?
• When does this rule not apply? What are the exceptions?
• How do you handle a situation where two rules conflict?
• What does a new hire need to know in their first month?

These are the questions that define the schemas and skills. You already know the answers. The engineering team structures them.

What This Looks Like in Practice

Here’s a realistic scenario. Your company decides to implement Business-as-Code for the customer success department.

Week 1: Knowledge audit. An engineer (or a NimbleBrain embedded team) sits with your head of customer success for 2-3 focused sessions. They ask: what entities does your team work with? What decisions consume the most time? Where does tribal knowledge create bottlenecks? The output is a map of 8-12 entities and 15-20 decision processes.

Your involvement: 3-4 hours across 2-3 sessions. You’re describing what your team does, not writing anything technical.

Weeks 2-3: Encoding. Engineers define schemas for the entities and write skills for the highest-value decisions. They bring these back to you and your team leads for review.

Your involvement: Review sessions where you read structured documents and say “yes, this is right” or “no, the exception for enterprise customers works differently.” You’re validating accuracy, not writing code. Budget 2-3 hours across the two weeks.

Week 4: Agent deployment. Agents start handling the encoded tasks. Some they handle well. Others expose gaps: a missing exception, a decision branch that doesn’t account for a seasonal pattern.

Your involvement: Reviewing agent outputs and flagging where they got something wrong. Each flag becomes a specific improvement to a schema or skill. Budget 1-2 hours.

Ongoing: The Recursive Loop continues. Each cycle adds more coverage. Your involvement drops as the system matures, from 3-4 hours per week initially to 1-2 hours per month for maintenance and refinement.

Common Concerns

“This sounds like another documentation project.” It’s not. Documentation decays because no one reads it. Business-as-Code artifacts stay current because agents use them daily. A stale schema produces visible errors. A stale skill produces wrong outputs. The system forces maintenance because the consequences of staleness are immediate, not theoretical.

“My team won’t have time for this.” The initial investment is 5-10 hours of domain expert time across the first month. That’s it. After that, the system handles the routine decisions that currently eat your team’s time. In NimbleBrain engagements, we see 3.2x average efficiency gains. Your team gets that time back, and then some.

“AI is going to replace my people.” No. AI handles the routine decisions that your people shouldn’t be spending time on anyway. A senior customer success manager who spends 4 hours a day on manual ticket routing now spends that time on the strategic work that actually requires a human: the conversations, the relationship management, the judgment calls that no schema can encode. Business-as-Code doesn’t eliminate roles. It eliminates drudgery.

“We already tried an AI project and it failed.” Most AI projects fail because the AI has no context about the business. That’s the whole point. The Pilot Graveyard (where 95% of AI pilots go to die) is full of capable AI models that were deployed without Business-as-Code. The models work fine. The missing piece is the structured knowledge that tells them how your specific business operates. That’s what Business-as-Code provides.

What It Comes Down To

You don’t need to become technical. You don’t need to learn JSON or markdown or git. You need to do what you already do (know your business) and articulate that knowledge clearly when asked.

The engineering team handles the structure. The agents handle the execution. You handle the domain expertise. That’s the division of labor in Business-as-Code, and it depends on non-technical leaders more than anyone.

Your knowledge is the raw material. Without it, schemas are empty forms and skills are generic checklists. With it, they’re the operating system that makes AI work on your specific business. Your role isn’t peripheral to this. It’s central.

For the full technical introduction, see BAC Explained. For a comparison to traditional operations, see BAC vs. Traditional Ops.