befound.labsWhatsApp

Engineering

The websites are the front door.This is the workshop.

I build AI systems for a living — retrieval over regulated document sets, agent graphs that other engineers have to maintain, tool servers sitting between a language model and a production database. A booking assistant for a decor studio is the small, well-behaved cousin of that work, which is exactly why I am comfortable putting one on your phone.

orchestrator/state.py
class ConversationState(TypedDict):
    intent:   Intent | None
    slots:    Slots          # occasion, date, area
    missing:  list[str]
    quote:    Quote | None
    approved: bool
    trace:    list[Step]


def route(s: ConversationState) -> str:
    if s["missing"]:                 return "ask"
    if s["intent"] is Intent.QUOTE:  return "quote"
    if s["quote"] and not s["approved"]:
        return "hold"                # a person sends it
    return "answer"

2 yrs

shipping AI systems in production

3

production systems with an agent layer

1

peer-reviewed paper, IEEE

What I actually work on

Three systems, none of them a chatbot.

Employers and clients aren't named here — the first is under NDA and the second isn't my platform to advertise. What they're built from is exact.

Day job · since 2025

An enterprise AI intelligence platform for a US healthcare group

An internal platform that lets staff ask questions of a very large body of regulated company documents and get an answer with its sources, rather than filing a request and waiting two days.

  • Python
  • FastAPI
  • LangGraph
  • AutoGen
  • MCP
  • MongoDB Atlas Vector Search
  • Docker
  • Kubernetes
  • Built retrieval pipelines over enterprise document corpora — chunking, embedding, and vector search on MongoDB Atlas — with the citation trail carried all the way through to the answer.
  • Composed the agent layer as a graph rather than a chat loop: typed state, explicit routing between steps, and a defined failure edge for every node.
  • Wrote MCP servers that expose internal systems to the agents as tools, so the model asks for data through a contract instead of being handed a database.
  • Shipped the services as FastAPI on Kubernetes, with the usual unglamorous half — timeouts, retries, structured logs, health checks.

The interesting part

Regulated fields have to be unreadable at rest, but the platform still has to query them. Current work is MongoDB client-side field-level encryption inside the framework: the data is encrypted and decrypted in the application, the database only ever stores ciphertext, and the key material never reaches it. Deterministic encryption on the fields that must remain matchable, randomised on everything else. The verification step is the honest one — insert with the encrypting client, read back with a plain client, and confirm you get binary you cannot understand.

Freelance · since Jan 2026

The AI layer of a fund and portfolio management platform

A development-finance investor's system for funds, investments, disbursements, ESG compliance against IFC Performance Standards, and risk. The product already existed; the AI layer did not. I was the engineer who built it, end to end, on top of a live SQL Server schema.

  • Python
  • FastAPI
  • MCP
  • GPT-4o function calling
  • SQL Server
  • React
  • Built an MCP tool server exposing roughly forty-five business operations over the existing database — each one a typed, permissioned contract rather than free-form SQL from a model.
  • Built a conversational form assistant: an investment officer describes a deal in a sentence, and the agent fills a long multi-field form, validating each field against the same rules the UI enforces.
  • Automated the risk workup — inherent, contextual and systemic risk plus outlook — as rules-based scoring for the numbers with a model writing the narrative, never the other way round.
  • Put a human approval gate in front of anything that writes. The agent proposes; a person commits.

The interesting part

Letting a language model near an investment database is the easy version of this problem to get wrong. The scores are computed by rules, deterministically, and are reproducible without a model in the loop at all — the model's job is to explain a number it did not choose. Every tool is scoped, every write is staged behind an approval, and the agent cannot reach anything the tool server does not explicitly expose. That constraint is the product, not a limitation of it.

This studio

The assistant stack behind the sites I sell

The same shape of system, sized for a business with one owner and a phone. An enquiry arrives at midnight; by morning it has been understood, priced, logged and drafted a reply.

  • Python
  • FastAPI
  • Next.js
  • OpenAI SDK
  • SQLite
  • Vercel
  • Five narrow workers behind one orchestrator — qualify, quote, follow up, write content, answer reviews — each with a single job it can be tested on.
  • Typed conversation state carried between steps, so the routing is inspectable and a failed run can be replayed rather than guessed at.
  • Quotes priced against the owner's real rate card by code, with the model doing the reading and the wording, never the arithmetic.
  • A fallback path that answers from written rules when the model is unavailable or the day's budget is spent, so the assistant degrades instead of dying.

The interesting part

Nothing goes out unsent. Follow-ups to quiet leads are drafted in the owner's voice and wait for a thumb on a phone, because a decor studio's reputation should not depend on a language model's judgement at 2am. It is a smaller decision than it sounds and it is the one that makes the difference between a tool a business keeps and one they switch off in week three.

How one is put together

An agent is a graph, not a personality.

This is the shape of the assistant that would sit behind your site — the same shape as the larger systems, with fewer nodes.

EnquiryWhatsApp or formRouterTyped state, in codeQualifyValidated schemaToolsRate card, calendarQuotePriced in codeHuman gateNothing self-sendsReplyLogged, with trace

Two things in that picture do most of the work. The router is ordinary code reading typed state, so the same enquiry takes the same path every time and a wrong answer can be opened and read rather than reproduced by luck. And the tool boundary means the model never touches your database — it asks for a rate-card lookup, by name, and gets back exactly that.

Run trace

The unglamorous half

Every rule here came from something that broke.

Structured output, then validate anyway

A schema on the model call is a request, not a guarantee. The parse is wrapped and the failure path is written before the happy path is.

Deterministic where it matters

Prices, scores and totals are computed by code that runs identically twice. Models write sentences about those numbers; they do not produce them.

Every run is replayable

Typed state and a stored trace, so a wrong answer can be opened and read rather than reproduced by luck.

Budgets, not hopes

Token ceilings per conversation, a daily cap across everyone, timeouts on every outbound call. An endpoint that spends money needs a limit that is not a promise.

Degrade, never die

If the model is down or the cap is hit, the system answers from written rules. A visitor should not be able to tell that something is wrong.

Measure the retrieval, not the vibe

A RAG system that feels good and a RAG system that is right diverge quietly. Fixed question sets, scored on whether the correct source came back at all.

The stack, split honestly

Daily

What I write, debug and ship in.

  • Python
  • FastAPI
  • LangGraph
  • AutoGen
  • MCP
  • OpenAI SDK
  • RAG pipelines
  • MongoDB vector search
  • Docker
  • Kubernetes
  • TypeScript
  • Next.js

Worked with

In production systems, alongside the people who own them.

  • AWS (S3, SQS)
  • Azure OpenAI
  • SQL Server
  • Neo4j
  • PyTorch
  • ArgoCD
  • Azure DevOps
  • React
  • Node.js

Reading, not shipping

Enough to be useful in a design conversation. Not enough to bill you for.

  • Kafka
  • Flower / federated learning
  • C# / .NET

Three lists rather than one, because a single list of everything you have ever touched tells a reader nothing.

If you want the technical version of the pitch, ask for it.

I'm happy to go through how the assistant would be wired to your business, what it can and can't decide on its own, and where the costs sit. It's a better conversation than a brochure.