How we think about AI systems.

Retrieval-augmented generation

A language model only knows what it was trained on. It has never seen your contracts, your tickets, or your product docs, and asking it about them invites confident nonsense. RAG fixes this by splitting the job in two: a retrieval step finds the passages of your data most relevant to the question, and the model then answers using those passages as source material.

The retrieval step is where these systems are won or lost. How documents are chunked, how they are embedded, how results are ranked and filtered, and how much context the model receives all matter more than which model you pick. A well-built RAG system cites its sources and says so when the answer is not in the data. A poorly built one is a liability with a chat interface.

GraphRAG

Plain RAG treats your data as a pile of independent text chunks. That works until the answer depends on relationships: which customers are affected by this contract clause, how this component depends on that one, who approved what and when. Similarity search alone cannot follow those threads.

GraphRAG builds a knowledge graph over the data first, capturing entities and the relationships between them, and lets retrieval traverse that structure. The model can then answer questions that span many documents at once. It costs more to build and maintain, which is exactly why it should be used where relationship-heavy questions are the core of the problem, and skipped where they are not.

Agentic architectures

An agent is a model given tools and a goal instead of a single prompt. It can search, run code, query systems, and take the next step based on what it just learned. Chained together, agents can handle work that no single prompt could: multi-step research, document pipelines, operations that touch several systems.

Agents raise the stakes. A system that acts is harder to make safe than a system that answers. The engineering that matters is in the boundaries: what the agent is allowed to do, how its work is checked, what happens when a step fails, and where a human stays in the loop. We design agent systems with small, verifiable steps and clear stopping conditions, because autonomy without guardrails is just an outage you have not had yet.

Why the engineer still matters

AI tools have made it genuinely easy to produce code. A working prototype is now a weekend project. We think this is great, and we use these tools every day. But it has created a new failure mode: applications that demo well and then collapse under real users, real data, and real time.

The reason is simple. Generating code was never the hard part of software engineering. The hard part is the decisions the code embodies. What happens when ten thousand people hit this endpoint at once. Where the data lives, and what guarantees it needs. What fails first, and what the system does about it. Which abstractions will still make sense two years of features from now. An AI assistant will happily produce something plausible for each of these. It takes an experienced engineer to know which plausible answer is wrong.

We have spent years making those decisions and living with the consequences, which is the only way anyone learns to make them well. That judgment is what we actually sell. The code is just where it ends up.