Schemas: Your Business Data Model

Every business runs on shared definitions. What counts as a customer. What fields an order requires. Which stages an onboarding process moves through. These definitions exist in your organization right now, scattered across spreadsheets, tribal knowledge, Slack threads, and the heads of people who’ve been around long enough to know. None of it is written down in a format that a machine can use.

Business schemas fix that.

What Business Schemas Are

A schema is a structured definition of a business entity. Think of it like a form but instead of a PDF that a human fills out, it’s a JSON document that defines exactly what fields exist, what types of data each field accepts, which fields are required, and what constraints apply. The critical difference: an AI agent can read this form, validate data against it, reason about it, and execute on it.

JSON Schema is the format. It’s an open standard, widely adopted, and readable by both humans and machines. When you define a customer as a JSON Schema, you’re saying: “This is what a customer IS in our business. These are the fields. These are the rules. Any system (human or AI) that touches customer data follows this definition.”

This is the core of Business-as-Code. Instead of business knowledge living in people’s heads or decaying in wiki pages nobody reads, it lives in structured, versioned, executable definitions. Schemas are the data model layer of that approach.

Why does this matter for AI? Because AI agents without structured context are guessing. They can generate plausible-sounding answers about your customers, but they don’t actually know what a customer means in your business. They don’t know that “enterprise” customers require a different approval flow than “SMB” customers. They don’t know that annual revenue below a certain threshold triggers a different pricing model. Schemas give agents that knowledge: not as a suggestion, but as a constraint they can validate against.

The difference between an AI agent that has your business schemas and one that doesn’t is the difference between an employee who’s read the operations manual and one who’s winging it on day one.

At NimbleBrain, we publish our own schemas at schemas.nimblebrain.ai, real JSON Schema definitions that our agents validate against in production. This isn’t theoretical. It’s how we build.

Types of Business Schemas

Business schemas fall into three categories, and together they cover the full range of business knowledge that AI agents need.

Entity Schemas

Entity schemas define the nouns of your business: the things that exist and have properties. These are the most intuitive schemas because they map directly to concepts your team already uses.

• Customer schema: Defines what makes a customer record complete, name, segment, revenue tier, primary contact, lifecycle status).
• Order schema: Defines what an order contains: line items, quantities, pricing, fulfillment status, approval chain.
• Product schema: Defines product attributes, SKU, category, pricing tiers, availability, specifications.
• Employee schema: Defines team member records, role, department, certifications, reporting chain, permissions.

Entity schemas are the starting point for most implementations. If your AI agent is going to work with customer data, it needs to know what a customer is.

Process Schemas

Process schemas define the verbs: the workflows and sequences that move your business forward. They capture the steps, transitions, and conditions that govern how work gets done.

• Onboarding workflow: Defines the stages a new customer moves through: from signed contract to fully activated, with required actions at each stage.
• Approval chain: Defines who approves what and when: dollar thresholds, role requirements, escalation paths.
• Support escalation: Defines how a support ticket moves from tier 1 to tier 2 to engineering: triggers, SLAs, handoff requirements.

Process schemas turn your SOPs into executable definitions. An AI agent with your onboarding schema doesn’t just know the steps: it can track where a customer is, what’s blocking them, and what needs to happen next.

Rule Schemas

Rule schemas define the logic: the business rules, conditions, and policies that govern decisions. These are the schemas that capture the knowledge most likely to live in someone’s head.

• Pricing rules: Defines how pricing works: base rates, volume discounts, contract overrides, promotional adjustments.
• Routing rules: Defines how work gets assigned: by geography, by product line, by customer tier, by agent availability.
• Escalation rules: Defines when and how situations escalate: SLA breaches, customer sentiment thresholds, revenue-at-risk triggers.

Rule schemas are where AI agents get the most operational value. Without them, an agent might know what a customer is (entity schema) and how onboarding works (process schema), but it won’t know that enterprise customers in the Pacific region get routed to a specific team.

Anatomy of a Schema

Here’s what a real business schema looks like. This is a customer entity schema in JSON Schema format:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Customer",
  "type": "object",
  "properties": {
    "name": { "type": "string", "description": "Full legal name" },
    "segment": { "type": "string", "enum": ["enterprise", "mid-market", "smb"] },
    "annual_revenue": { "type": "number", "minimum": 0 },
    "primary_contact": { "type": "string", "format": "email" },
    "onboarding_status": { "type": "string", "enum": ["pending", "active", "churned"] }
  },
  "required": ["name", "segment", "primary_contact"]
}

Walk through each part:

$schema declares which version of JSON Schema this follows. Think of it as declaring the language version. Using Draft 2020-12 gives you the full modern feature set.

title names the entity. This is what the schema represents: in this case, a Customer.

type: "object" says this schema describes a structured entity with named fields, not a single value.

properties is where the fields live. Each field has a name, a type, and optional constraints:

• name is a string. The description tells both humans and agents what this field means.
• segment is a string, but constrained to three specific values via enum. An agent can’t set segment to “big company”. It has to be “enterprise”, “mid-market”, or “smb”.
• annual_revenue is a number with a minimum of 0. Negative revenue isn’t valid.
• primary_contact is a string with format: "email" (the schema knows this isn’t just any string, it’s an email address).
• onboarding_status uses enum to define the three valid lifecycle states.

required lists the fields that must be present. A customer record without a name, segment, or primary contact is invalid. Revenue and onboarding status are optional. They can be filled in later.

This schema is 15 lines. A business leader can read it in two minutes. An AI agent can validate against it in milliseconds. That’s the point.

How Schemas Power AI Agents

When an AI agent has your customer schema, it doesn’t just know that customers exist: it knows what a customer IS. It knows the fields, the types, the constraints, the valid values. This changes what the agent can do.

Validation. The agent can check incoming data against the schema. If someone tries to create a customer with segment “big company”, the agent flags it: the valid values are enterprise, mid-market, and smb. No hallucination. No guessing. The schema is the authority.

Decision-making. The agent can route decisions based on schema fields. Enterprise customers get a dedicated account manager. Customers with annual revenue above a threshold get priority support. These decisions come from the schema’s structure, not from a vague prompt telling the agent to “handle customers appropriately.”

Form generation. The agent can generate data entry interfaces directly from the schema: correct fields, correct types, correct validation. No manual form building. The schema is the source of truth.

Cross-entity reasoning. When the agent has schemas for customers, orders, and products, it can reason across them. It can connect a customer’s segment to their order history to their product usage. It can identify patterns that span entities because it understands the structure of each.

Without schemas, an AI agent is operating on vibes. It’ll produce reasonable-looking output, but it has no ground truth to validate against. It doesn’t know your rules. It doesn’t know your constraints. This is the Context Engineering problem and schemas are the most direct solution. They give agents the structured context they need to operate on your business, not just talk about it.

Getting Started

Start small. You don’t need 30 schemas on day one.

Pick your 5 most important entities. These are usually obvious: customer, order, product, employee, and whatever domain-specific entity is central to your operations (patient, property, shipment, claim). Write a schema for each.

Keep schemas simple at first. 5-10 fields per entity. Required fields only for what’s truly required. You can always add fields, constraints, and relationships later. A simple schema that agents actually use beats a complete schema that nobody maintains.

Use descriptions liberally. The description field in JSON Schema exists for a reason. “Full legal name” is better than just name. “Annual recurring revenue in USD” is better than just annual_revenue. These descriptions help both human readers and AI agents understand intent, not just structure.

Version your schemas. Put them in git. Treat changes to business schemas like you’d treat changes to a database schema, review them, test them, document what changed and why. Your business definition is as important as your code.

Reference real examples. We publish schemas at schemas.nimblebrain.ai as a starting point. These aren’t templates you copy, they’re reference patterns that show how to structure entity, process, and rule schemas for real business operations.

Iterate based on agent behavior. Once agents are validating against your schemas, watch where they fail. A field that’s always empty might not be needed. A constraint that’s constantly overridden might be wrong. An enum that’s missing a value shows a gap in your model. Schemas are living documents. They improve as your agents use them. This is the Business-as-Code loop: define, deploy, observe, refine.

The goal isn’t perfection. The goal is to get your business knowledge out of people’s heads and into a format that machines can act on. Five simple schemas deployed to production beat fifty detailed schemas sitting in a wiki.