How we ship production AI — not how we talk about it.

Agent + MCP server layer

We build the agent and the MCP servers that give it usable hands. Tools, retrieval, memory, and authorization live in a layer we own — not stitched together as one-off function calls. That separation is what makes the system testable, upgradeable, and survivable past the first model version.

• Custom MCP servers per integration. Each system of record gets a typed server with versioned tool schemas, structured error handling, and explicit authorization scopes — not raw API wrappers.
• Agent loop in Python. Anthropic SDK, deterministic state machine around the model, structured tool use, retry and fallback policies that survive model swaps.
• Retrieval as a first-class tool. We treat retrieval as an integration, not a search bar: source-of-truth indexing, freshness policy, and provenance returned with every answer.

Real systems of record, not scraping

Most AI proofs of concept die at the integration boundary. We don't build against synthetic data, sandbox accounts, or browser automation that breaks at the first DOM change. Our MCP servers connect to authoritative systems through the same auth, identity, and permission boundaries the partner already trusts.

• Direct API integration first. CRMs, ERPs, ticketing systems, data warehouses, file stores. Where APIs don't exist, we build adapters — not scrapers.
• Identity and permissions inherited. The agent operates inside the partner's existing auth/RBAC model. No service-account shortcuts that turn into compliance issues later.
• Event-driven where it matters. For workflows that need to react, not just respond: we stand up event consumers so the agent acts when the partner system changes, not only when a user asks.
• Human-in-the-loop by design. Approval gates, escalation paths, and audit trails for anything the agent shouldn't decide on its own.

Eval harness and production observability

An AI system that nobody is measuring isn't a system — it's a liability with good marketing. Every Fulcrum engagement includes an eval harness scoped to the partner's operating metric, and an observability layer that survives the demo and into year two.

• Pre-launch: golden sets and regression tests. Scenario coverage tied to the partner's real intents, run on every prompt and model change, gated in CI before merge.
• Structured production traces. Every tool call, every model turn, every retrieval hit — stored with prompt, response, and outcome so the team can debug a specific user moment, not vague aggregates.
• Drift detection. We watch the things model providers don't: latency distribution shift, refusal rate, tool-call success rate, retrieval freshness. We page on them, not just on uptime.
• One operating metric per engagement. Every engagement opens with the number we expect to move and how the eval will tell us when we've moved it.

Governance: the answer to "what if it goes wrong"

Every AI committee eventually asks two questions that matter more than any benchmark: can you show me exactly what the agent did, and can you stop it before it does something worse. We build governance into the agent layer from day one — it's not a compliance doc bolted on after a committee asks for it. We structure this around seven controls we call IADTHAM.

• Identity. Every agent runs under its own identity — a service principal, not a shared API key. You always know which agent, which session, which run.
• Authorization. Agents inherit the partner's existing RBAC and permission model. An agent can't read or write anything a human in its role couldn't.
• Data control. Read-only by default. Write actions are explicitly scoped per tool, per system — no blanket database access.
• Tool control. Every tool an agent can call is enumerated and versioned. Adding a new capability is a reviewed change, not an emergent behavior.
• Human in the loop. Approval gates and escalation paths on anything the agent shouldn't decide alone, defined before launch — not discovered after an incident.
• Auditability. Structured, timestamped traces of every model turn and tool call. Recreating exactly what an agent did last Thursday is a query, not an investigation.
• Monitoring. Drift detection, refusal-rate tracking, and a kill switch that reaches every level — one asset, one channel, or the whole system — activated in under 60 seconds, without vendor intervention.

See how IADTHAM works in practice →

Optimization: keeping the token bill honest

The question we hear most from finance and ops leaders isn't "does the model work" — it's "what happens to our bill when usage scales 10x." We build cost and performance discipline into the agent layer itself, not as a dashboard you check after the invoice arrives.

• Model routing. Not every call needs the most expensive model. We route easy, high-volume calls to smaller models and reserve frontier models for the calls that actually need the reasoning depth — often the single biggest cost lever in a deployment.
• Context and prompt efficiency. Bloated prompts and redundant context are the quiet tax on every call. We trim system prompts, cache stable context, and avoid re-sending what the model already has — before touching the model choice.
• Caching and reuse. Repeated or near-duplicate calls get served from cache instead of re-run against the model. For high-volume, template-driven workflows this alone can cut spend substantially.
• Usage budgets and alerts. Per-agent, per-tenant usage tracking with budgets and overage alerts, so a runaway loop shows up as a page — not a surprise on next month's invoice.
• Latency as a cost lever. Streaming responses, parallel tool calls, and async where the workflow allows it. The fastest system is usually also the cheapest one, since cost scales with tokens-in-flight and retries.
• Tuning against the eval harness. Optimization isn't just cost — prompt and retrieval tuning run against the same eval suite from Evaluation, closing the loop between "cheaper" and "still accurate enough to trust."

The engagement model

Partners hesitate on AI partnerships for a real reason: most of them are open-ended. Ours isn't. Every Fulcrum build partnership runs through four phases with explicit deliverables, durations, and exit conditions. The partner knows what they're getting and when.

• Weekly written check-in. What shipped, what's stuck, what the eval shows. Same format every time.
• One technical owner. A Fulcrum engineer owns the build end-to-end. Partners don't get rotated through a bench.
• No deliverables that can't be run. If we can't show you the system or the eval result, we haven't delivered it.