AI-Native Products
Not chatbots. The orchestration, billing, and observability underneath production agentic systems — routing that knows its own confidence, execution a human can veto, and output that cannot drift past its contract. Shipped in Resolo, Saldo, and Checkmarked.
Orchestration and guardrails for an existing product fit a 2–4 week sprint.
An AI-native product is one where the model is a component inside a system, not the system itself. The engineering is mostly the boundary around it: what the model is allowed to propose, what validates the proposal, who can veto it, what gets logged, and what it costs. A demo needs none of that. A product in front of customers needs all of it.
- PRODUCTS SHIPPED
- 3
- PROVIDERS
- 3
- FROM
- €5,000
- SCHEMA-BOUND
- 100%
HOW IT RUNS
WEEK 1 → WEEK 4- WEEK 1
Bind the output
The schema the model has to satisfy, written first. Every guarantee downstream depends on that boundary holding.
- WEEK 2
Tools and retrieval
The functions the model is allowed to call and the data it is allowed to see, each behind its own permission check.
- WEEK 3
Evals and refusal
A test set with expected answers, plus the defined behaviour for when confidence is too low to act at all.
- WEEK 4
Cost and latency
Caching, model routing, and a real number for what one session costs before a customer ever sees it.
HOW IT IS BUILT
- Orchestration with explicit handoffs
- Confidence-tagged routing and explicit handoff markers, so an agent defers to a specialist, a tool, or a human deliberately rather than hallucinating past the edge of what it knows.
- Human-in-the-loop execution
- AI proposes as a structured preview; a hardened executor applies it, with validation, encryption, and audit trails throughout. The model never holds the write path on its own.
- Constrained outputs
- Zod schemas around every model call and centralized prompts, so output cannot invent a field or a category the product does not handle. A schema violation is recoverable information, not a crash.
- Multi-model and metered
- OpenAI, Anthropic, and Google under one orchestration layer, with token-to-credit ledgers attributing cost per organization, per call. Model choice becomes configuration rather than migration.
- Retrieval that is actually scoped
- pgvector knowledge layers partitioned per tenant. Retrieval that can reach another customer's documents is not a feature with a bug — it is a breach.
SHIPPED
Not a capability list — software in market that this work produced.
- CUSTOMER SUPPORTRESOLOCustom orchestration engine with confidence tags and explicit handoff markers. pgvector knowledge layer, Redis-backed escalation, billing tied to plans.TypeScript · pgvector · RedisCASE STUDY
- FINTECHSALDOTwo-phase orchestration — AI proposes, hardened executor applies. Self-healing import configs, vision-augmented parsing, pluggable e-invoicing connectors.Next.js · Vercel AI · Postgres · RedisCASE STUDY
- DEVELOPER TOOLSCHECKMARKEDTwo-stage analysis pipeline: deterministic scan for instant feedback, deeper AI passes for narrative. SSE streaming, Zod-bound outputs, multi-repo support.Next.js · Azure OpenAI · PostgresCASE STUDY
WHAT YOU GET
- Orchestration layer with routing, confidence thresholds, and handoff events
- Schema-bound model calls with centralized, versioned prompts
- Human review surface for anything the system proposes
- Per-organization usage metering and cost attribution
- Evaluation harness and replayable session logs
- Provider abstraction so a model can be swapped without product changes
- TypeScript
- Zod
- Vercel AI SDK
- pgvector
- Postgres
- Redis
- OpenAI
- Anthropic
- Azure OpenAI
THE ARTIFACT
IS THIS THE RIGHT FIT
- AI touches real data, real users, or real money in your product
- You need to explain after the fact why the system did what it did
- Cost per customer has to be attributable
- A prototype where a single prompt and a text box is genuinely enough
- Model training or fine-tuning research — that is a different discipline
QUESTIONS
Do you build chatbots?
Not as the goal. The work is the orchestration underneath — routing, validation, human review, metering, and observability. A conversational surface is sometimes the output of that, but it is the least interesting part and the easiest to replace.
How do you stop the model doing something irreversible?
It never holds the write path. The model produces a structured proposal; a separate executor validates it against a schema, checks permissions and tenancy, and applies it inside a transaction, with an audit trail recording the model and prompt version that produced it.
Which model providers do you support?
OpenAI, Anthropic, and Google under one orchestration layer, plus Azure OpenAI where compliance requires it. Because every call is defined by a schema rather than a provider's response shape, switching providers is a configuration change.
GOING DEEPER
- Agents that know when to deferMost multi-agent systems fail at the seams. Confidence-tagged routing and explicit handoff markers make the seams visible — and make deferring to a specialist, a tool, or a human a decision the system takes deliberately.
- AI proposes, a hardened executor appliesLetting a model hold the write path is the mistake. Separating proposal from execution — structured previews on one side, a validating executor on the other — is what makes AI safe to point at real data and real money.
- Output that cannot drift past its contractA schema around every model call turns an unpredictable string into a typed value. Centralised prompts turn a scattered liability into a versioned asset. Neither is exciting, and both are what makes LLM features maintainable.
Got something in this shape?
A scoped sprint starts at €5,000 and runs two to four weeks. Every engagement is priced before work starts.