How I can help

I work with teams who have decided AI belongs in their product and now have to make it actually work. Engagements are usually one of the three shapes below, though the useful ones often start as a conversation rather than a scope document.

Agentic system design

Designing multi-agent and tool-using systems that do real work — and knowing where the boundary sits between an agent and a plain, predictable pipeline. Most systems I review need fewer agents than they have, not more.

What you get

  • Architecture blueprint: agent roles, coordination patterns, and control flow
  • Model and provider strategy across OpenAI, Anthropic, Gemini and open-weight options
  • Tool-calling and function-execution design for your existing systems
  • Memory design: short-term context handling and retrieval (RAG) where it earns its place
  • A written record of the tradeoffs, so your team can maintain it after I'm gone
Agentic system design illustration

Tools

LangChain LangGraph CrewAI AutoGen n8n

Evaluation & observability

The difference between a demo and a product is knowing when it's wrong. I build the measurement layer: evals that catch regressions, tracing that explains failures, and cost tracking that stops surprise invoices.

What you get

  • Automated evaluation suites for accuracy, relevance and safety on your own data
  • Tracing and observability wired into your existing monitoring stack
  • Prompt versioning and A/B comparison so changes are measurable, not vibes
  • Token cost and latency tracking, with model-selection guidance
  • Guardrails: PII detection, output validation, and failure containment
LLM operations and evaluation illustration

Tools

LangFuse Weights & Biases MLflow Elasticsearch Kibana

Backend & cloud architecture

AI features fail at the seams — queues, retries, data access, deployment. This is the part of my background that runs deepest: seventeen years of backend systems that had to stay up.

What you get

  • Service architecture and API design, including migration paths off a monolith
  • Event-driven systems with Kafka, Redis Streams or RabbitMQ
  • Data layer design: PostgreSQL, MongoDB, and vector stores where they fit
  • Containerization and orchestration with Docker and Kubernetes
  • CI/CD pipelines and infrastructure as code
Backend modernization illustration

Infrastructure

AWS GCP Kubernetes Kafka Redis PostgreSQL

How engagements usually work

I'm one person, which means I'm selective and I'm direct about fit. Here's the honest version.

Start here

Architecture review

A short, fixed-scope engagement. I read your system, talk to your engineers, and write up what I'd change and why. Often the fastest way to find out whether working together makes sense.

Most common

Build engagement

Hands-on design and implementation alongside your team, typically part-time over a few months. I aim to leave behind something your engineers can own, not a dependency on me.

Ongoing

Advisory retainer

Regular time for teams who have the engineers but want a second opinion on architecture decisions as they come up.

On availability: I currently work full-time as a Team Lead, so consulting capacity is limited and I take on work that fits around it. If you need a full-time contractor, say so — I'm open to the right long-term arrangement and we should talk about that directly.

Not sure which one you need?

That's normal. Describe the problem and I'll tell you honestly whether I'm the right person for it.

Start a conversation