You're technical.
Let's get into it.

01Agentic systems

Give the system a job. Define its limits.

We design systems that can use tools, inspect the results and choose their next step. That might be a research assistant following evidence across documents, an operations assistant preparing a change for approval, or a worker resolving a queue of bounded tasks.

We start by deciding where a fixed workflow is sufficient and where model-directed decisions are useful.

• Tool contracts with typed inputs, validated outputs and permissions enforced by the application.
• Persistent task state, timeouts, retry limits and idempotent writes so a retry cannot silently repeat an action.
• Step, token and spend budgets, with explicit stopping conditions and approval for consequential actions.

In the scope Workflow design, tool interfaces, approval paths and tests for failed or interrupted runs.

02RAG & context

Get the right evidence into the answer.

Retrieval-augmented generation gives a model relevant source material at request time. We work on the ingestion and retrieval pipeline as well as the prompt, from messy PDFs and changing product records to internal knowledge bases.

• Parsing, chunk boundaries and metadata that preserve the relationship between a passage and its source.
• Keyword and semantic retrieval, reranking and context selection tested against real questions.
• Access checks before material enters model context, plus document refresh, deletion and citation handling.
• Explicit behaviour when sources are missing, contradictory or too weak to support an answer.

In the scope An ingestion pipeline, retrieval baseline and evaluation set that separates missing evidence from poor answers.

03Vector stores & search

Choose the store around the workload.

A vector store holds embeddings for similarity search. The useful questions are about the workload: how much data, how often it changes, which filters apply and how much recall you need at a given latency.

We can assess whether vectors belong alongside relational data, for example in PostgreSQL with pgvector, or in a dedicated search service.

• Embedding model, dimensions, distance metric and versioning, with a plan for re-embedding when those choices change.
• Exact versus approximate search, index memory, build time and measured recall under realistic filters.
• Tenant boundaries, source IDs and deletion propagation, including what happens when access is revoked.

In the scope A storage recommendation, representative search benchmark and a plan for index changes and backfills.

04Evals & regression testing

Know what improved. Catch what broke.

We turn the intended behaviour into a repeatable evaluation. That includes representative tasks, awkward inputs, expected failures and cases where the system should ask for help.

• Versioned datasets and baselines for prompt, model, retrieval and tool changes.
• Deterministic checks for things we can assert, such as schema validity, permitted actions and resulting database state.
• Human-reviewed rubrics for answer quality, with model graders calibrated against human judgements.
• Separate measures for retrieval quality, grounded answers, tool use and task completion. Repeated runs where variability matters.

We agree release thresholds with your team and turn useful production failures into regression cases.

In the scope An eval harness, baseline report and checks that can run in your delivery pipeline.

05Performance & cost

Measure the whole task.

We compare quality, latency and operating cost on the same workload. A cheap model call can become expensive once retries, tool calls and manual corrections are included.

• Median and p95 latency across the request, including retrieval, model calls, tools and queue time.
• Time to first token alongside time to a completed result, so streaming does not hide slow execution.
• Model routing, context size, output limits, concurrency and caching with appropriate tenant boundaries and invalidation.
• Batching for work that can wait, plus rate-limit handling and fallback behaviour for provider failures.

In the scope A workload benchmark and cost per successful task, with the quality and latency trade-offs made explicit.

06Architecture & integrations

Make the boundaries explicit.

We work through how a system fits your existing applications, data and operations. This includes where responsibilities sit, which dependencies can fail and what the user should experience when they do.

• Service and API contracts, synchronous requests versus background jobs, and clear ownership of state.
• Webhook authentication, deduplication, bounded retries and handling events that arrive out of order.
• Transaction boundaries, queues and outbox patterns where a database update must reliably lead to a downstream event.
• Integration tests, versioning and release plans that account for the systems your team does not control.

In the scope Architecture decisions, interface contracts and a delivery plan that names dependencies and failure paths.

07Database schemas & migrations

Change the system while people use it.

We design schemas around your domain, queries and data ownership. Constraints, indexes, tenant isolation and audit history are part of that design.

For an existing system, we plan application and database changes together. A typical approach is to expand the schema, backfill in batches, switch reads and writes, then retire the old shape once it is safe.

• Query plans and representative volumes before adding indexes or changing data structures.
• Lock behaviour, constraint validation and compatibility between old and new application versions.
• Restartable backfills, reconciliation checks and explicit recovery steps for destructive changes.

In the scope Reviewed schema changes, versioned migrations and a rollout plan with an agreed interruption budget.

08Security & observability

Make failures visible and contain them.

We treat retrieved documents, user input and tool responses as untrusted data. Prompts are only one part of the design; access control and action permissions belong in application code.

• Least-privilege credentials, isolated execution where needed, and approval boundaries around sensitive actions.
• Tests for prompt injection, unauthorised retrieval and misuse of tools, including indirect instructions in documents.
• Request traces with model, prompt and retrieval versions, tool results, timings and costs, with sensitive content redacted.
• Alerts tied to task failures and service objectives, plus runbooks for degraded providers and interrupted jobs.

In the scope A threat review, operational instrumentation and handover notes that tell your team how to investigate and recover.