Loading…
AI Integration — One Platform, Two Ways of Acting
Two products needed assistants that could understand real business data without inventing information or making unsafe changes. This project uses one reusable assistant foundation for both use cases.
- Role
- AI application engineering — designed and built a reusable assistant core and two business-specific adapters with retrieval, human-in-the-loop actions, and the routing logic connecting them.
- Stack
- Vercel AI SDKNext.jsTypeScriptZustandSupabaseTanStack Query
Overview
Chat, streaming, history, and artifacts live in one shared shell. The business logic — what the assistant actually knows and can do — is swappable. One adapter only needs to look things up safely. The other needs to act on real data safely. Same foundation, opposite risk profiles.
Most AI features get built once, bolted on, then rebuilt from scratch for the next app — this is a reusable core instead, with two very different products plugged into it.
Interface
One shell, two assistants
The Assistant Shell
Chat history, streaming responses, and artifacts — the reusable part neither adapter has to rebuild.
Interface
One shell, two assistants
The Assistant Shell
Chat history, streaming responses, and artifacts — the reusable part neither adapter has to rebuild.
Key features
One shell, two very different jobs
Four things that show the same platform doing opposite work — finding information safely, and changing real records safely.
Key features
One shell, two very different jobs
Four things that show the same platform doing opposite work — finding information safely, and changing real records safely.
Never invents a product
Every recommendation comes from a real catalog lookup — no fabricated SKUs, no guessed prices. If nothing matches, it says so honestly instead of making something up.
The conversation follows you
Move between pages and the assistant keeps talking — chat state survives navigation instead of resetting every click.
Nothing changes without approval
The assistant proposes a change and waits. A human confirms it. Only then is anything written — and it's re-checked for authorization at that exact moment.
Plays by the app's own rules
The assistant can't see or touch anything a human in the same role couldn't. Permissions are enforced at the data layer, not just hidden in the UI.
Technical approach
The mechanics behind each side — how retrieval stays honest, and how mutation stays safe.
Two pipelines, one shared foundation
The chat platform never imports business code. Each product plugs in its own logic through one contract — so a third product could join without touching the core at all.
One model call classifies the request. Everything after that — what to search, how to render it — is plain code, not another AI decision. The model never picks the catalog result itself.
The model plans what to do and drafts a proposal — it never confirms its own writes. A human approves, and only then does a separate, model-free step re-check permissions and make the change.
History, streaming, and artifacts are shared infrastructure. Everything about what the assistant knows and is allowed to do lives outside that core — swapped per product, never hardcoded into the shell.
Related Projects
More work in this space
Sandelia AI
An AI assistant platform for freelancers and small businesses — chat, streaming, and human-in-the-loop approval flows, built as the display layer for a LangGraph backend owned elsewhere.
Shopmate
The retrieval-first shopping assistant referenced above — product discovery, cart management, and generated artifacts, all from real catalog data. Visit Shopmate
Closer AI
The mutation-safe assistant detailed above — proposes changes, waits for confirmation, and verifies every write before it touches real data. Explore the CRM Platform
Results
One platform, proven in two directions
A single reusable assistant core powering two products with opposite risk profiles
Retrieval assistant with zero invented catalog data — every result traces to a real product row
Mutation assistant where the model never confirms its own writes — every change is independently re-verified before it's applied
Architecture built to support a third adapter without changing the shared core