Any SDK. We build and maintain at the seams.
The buyer's first objection is “you can't build or maintain my stack — it's on {SDK}.” The answer: we build against, and maintain against, a normalized set of seams every modern agent SDK exposes. The core scout + tester workflow already runs on three SDKs in production — Cursor, Claude Code, and Codex — and we've migrated a production harness between SDKs once already. The abstraction is production code, not a diagram: our own ticket orchestrator runs Claude Agent SDK and OpenAI Agents SDK executors side-by-side — identical tool surface, transcripts normalized at write time, one analysis + process-mining pipeline over both. And when there's no vendor SDK at all — a fully-custom build wired straight to the model (direct API, router, or local open-weight) — the control plane *is* the runtime: we implement the seven seams ourselves.
The seven normalized seams
Build and maintenance both attach to these — not to the SDK. When an SDK changes, the adapter absorbs the change; the logic above stays stable.
Per-SDK support
Cursor, Claude Code, and Codex are all production-proven in live customer projects — the core scout + tester workflow runs on all three across two engagements. The deepest full ten-layer maturity (OCPM, guardrails, reliability, CI/CD) is on the Cursor engagement; Claude Code and Codex harden to full depth on the engagement that needs it. We never present adapter-ready as production-proven.
Cursor SDK
The deepest engagement — the full ten-layer stack, built and run end to end. Deepest quirk knowledge.
Claude Code / Agent SDK
Scout + tester proven in production — and one of the two production executors in our ticket orchestrator, running live customer tickets under durable (Temporal) orchestration.
OpenAI Codex / Agents SDK
Scout + tester proven in production — and the second production executor in our orchestrator: identical tool surface, transcripts normalized so one analysis + process-mining pipeline consumes both SDKs.
Pi agent + open-weight model
Our daily production driver internally — customized Pi instances run orchestration tooling, safety auditing, cross-agent integrations. The no-proprietary-vendor path: data sovereignty, cost, air-gap. The engagement adapter graduates on the first customer run.
Fully custom · direct-to-model
No vendor SDK — a bespoke agent wired straight to the model, through any router, or to a local open-weight endpoint. The control plane is the runtime; we own all seven seams. Choose it for control, routing, determinism, and data sovereignty — true metered cost, not token savings.
| Capability domain | Cursor | Claude Code | Codex | Pi + open |
|---|---|---|---|---|
| Core scout + tester workflow (L1–L3) | Production | Production | Production | Adapter-ready |
| Guardrails / hooks (L4) | Production | Supported | Supported | Adapter-ready |
| OCPM workflow mining (L6) | Production | Supported | Supported | Adapter-ready |
| Reliability layer (L7) | Production | Supported | Supported | Adapter-ready |
| Security hardening (L8) | Production | Supported | Supported | Adapter-ready |
| CI/CD integration (L10) | Production | Supported | Supported | Adapter-ready |
Known-quirk catalog
Real, current quirk knowledge from production — the reference engagement and our own orchestrator. Every one cost real diagnosis time to discover — our customers inherit the catalog instead of paying to rediscover it.
On a different SDK? Tell us its shape.
If your stack runs on an adapter-ready SDK, the Stabilization Sprint hardens the adapter and starts its quirk catalog. We'll tell you honestly where it sits.
Email [email protected]