Your agents are running on the model's defaults.
They should be running on your company's logic.

FieldRules is the rule library your humans already confirmed. IF / THEN / BECAUSE, attributed and versioned. Your agent calls it the same way a PM or an engineer would — and inherits the same reasoning layer.

Request early access See the rule shape ↓
We shipped the agent. It handles the easy 60%. The other 40% is exactly the stuff our lead ops person used to decide — and now it’s being decided by the model’s defaults.
Staff engineer · Series B fintech— composite quote
The Shape

What a FieldRules rule looks like
to an agent.

Each rule is a structured record. IF and THEN describe the operational action. BECAUSE carries the reasoning — in the author’s own words.

Every field is either authored by a named person or derived from their confirmation. The rule is versioned. The author stays on the record. The BECAUSE is never machine-generated.

Your agent reads this record the same way a human queries it. When the library can’t match, the gap is structured context — not a 404 — and it routes back to the human who’d carry that judgment.

Honest caption Fields mirror the production schema. BECAUSE shown here is illustrative — in a real seeded library, because_clause is null until a domain expert authors it.
rule · JSON
{
  "rule_id": "82a96174-8080-4a60-bd45-af81cd12bf68",
  "revision_id": 3,
  "when_clause": "enterprise customer has completed kickoff AND first activity data upload spans ≥2 business units",
  "then_clause": "schedule a Week 2 data-quality review before any calculation is surfaced in the customer-facing dashboard",
  "because_clause": "Mixed-BU uploads in week one routinely mis-map activity categories. Catching it before the first readout is what preserves methodology defensibility — and the customer's trust.",
  "domain": "onboarding",
  "scope": "workflow",
  "hedge_tag": "usually",
  "status": "confirmed",
  "author_id": "jordan.chen@acme.co",
  "confirmed_at": "2026-04-21T09:48:47Z"
}
How It Works

Three steps.
MCP-native.

01
Humans populate the library
Your domain experts confirm rules in the flow they already work in — a Slack card, a web confirmation. Each confirmation produces a structured record with an authored BECAUSE. No separate documentation ritual.
02
Your agent queries it over MCP
The library runs as an MCP server. Your agent lists its resources, calls get_rule or search_rules for the cases that apply, and the BECAUSE travels with the IF/THEN. If MCP isn’t your path, the same records are reachable over a plain JSON endpoint — tool call or context injection, your choice.
03
Gaps route back to the right human
When the agent hits a case the library doesn't cover, FieldRules is designed to treat that miss as a demand signal — the right expert gets a live ask with context. The library grows from the gaps your agent actually encounters, not from documentation obligation.
The part no AI can write

Ingested knowledge covers the 60%.
FieldRules is the other 40%.

Adjacent category
Pull together your SOPs, support scripts, KB articles, and policy docs.
The premise is that your reasoning is already in the documents — the job is to make those documents agent-readable.
FieldRules
The reasoning is in your people’s heads. Elicit it; attribute it; ship it.
Your agent doesn't read your docs and hope. It calls rules your humans confirmed — with the BECAUSE they authored, attached to the IF/THEN.

Documentation produces compliance. FieldRules elicits reasoning — because it asks “what would go wrong if this rule didn't exist?” instead of “why does this rule exist?”

That single design choice is the difference between an agent that covers the easy cases and an agent that handles the ones that would have gone to your best human.

Where We Sit

Not the runtime.
The reasoning substrate.

FieldRules is not an agent, not an agent framework, and not a tool-calling runtime. It sits upstream of all three — the human-authored reasoning layer that your agent, your framework, and your runtime all call the same way.

Same rule library, same reasoning, same governance — different caller.
Agent
Your CX, ops, or support agent — whatever you built or bought.
Framework
OpenAI Agents SDK, LangGraph, Claude, Gemini, custom — doesn't matter.
Runtime
Tool-calling, retrieval, policy-as-code enforcement. Runtime concerns.
FieldRules
Human-authored reasoning. Provenanced, versioned, queryable. The layer every caller above inherits.
Framework compatibility

If your stack speaks MCP,
it already speaks FieldRules.

MCP clients OpenAI Agents SDK LangGraph Claude Agent SDK Gemini Agents Custom orchestration

MCP is the canonical caller — list the resources, call what applies, the BECAUSE travels with the record. A plain JSON endpoint is there if you’re not on MCP yet. Same library. Same reasoning. Different transport.

Your humans already confirmed the reasoning.
Let your agent inherit it.

We're onboarding teams with an agent in production or in pilot. If that's you, let's talk about the integration shape. No deck. No demo-ware.

We start with a conversation.