alex → consulting

past work, and how an engagement runs.

most of the consulting i have done has been one of two things. sometimes a team had an llm prototype that demoed well and broke in production, and wanted help finding out why. in my experience the problem is rarely the model. it is usually the data model, the evals, or how failures are handled. other times a team was earlier than that, and wanted a second opinion on whether ai belonged in their product before they committed to building it. i still take on a few engagements a year.

how an engagement runs

  1. a conversation

    it starts with an initial conversation: what is there already, and what is actually painful.

  2. deciding what to address

    from there we decide what to address, and how to do it in a simple proof of concept.

  3. a quick proof of concept

    one to two weeks. small, but built as the structured foundation the rest can be built on over time.

  4. then, if it helps

    optionally, further engagement: the full implementation, or advising while the implementation happens.

past work

a knowledge platform and ai copilot

built an ontology-powered knowledge platform and ai copilot for mapping client organizations: organizing references to documentation, identifying conflicts or gaps in understanding, and synthesizing insights and reports across the documents it can access. all packaged as a web app with chat, graph visualization, task tracking and document management.

a small management consulting firm

personal knowledge agents

developed personal knowledge management agents in claude code and obsidian for founders, executives, consultants and creatives. they capture and file notes into the vault, link them and keep its structure consistent, run reviews that synthesize across notes, and research and draft from what is already there. built from claude code skills and commands, hooks, mcp servers and vault conventions, then set up for each person and taught as a few plain-language commands.

non-technical individuals

llms for internal processes

they were deciding how to use llms internally, to accelerate their own processes. this was an early look at whether to self-host or use an llm api, how to maintain a living eval set that moves with expected behavior, and how to put guardrails in the workflows.

an identity verification startup

from a data model to the first demos

started as consulting: built the data model, and set them up with supabase for the database and auth, fastapi and sqlalchemy for the api, and langchain and langsmith for agents. then defined the first demo workflows.

an early-stage startup

codifying organizational process

as interim coo, helped codify how the organization managed its processes: raci matrices, documented processes, access controls aligned across the org, platforms locked down, and process built into internal tooling.

a blockchain unicorn

an llm keynote

a virtual keynote for about 30 cios and founders: an introduction to llm architectures and what they can do, how to protect workflows with guardrails, and how to build virtuous loops in an organization that make the most of automation and feedback.

an australian vc