Six tools in one web app that put a team's scattered manual work behind purpose-built screens.

The actual value is unification: before the Hub, the work meant moving between systems by hand. One place now fronts several internal APIs, and it cut the team's manual effort substantially — duplicate handling, catalogue search without SQL, nearest-destination lookup by coordinates, bulk duplicate processing, mismatch inspection, each a focused screen.

Some tools are LLM-backed to make the judgement calls easier: a model evaluates candidates and returns a structured decision with a one-line reason, so the reviewer has something to audit. The model assists the reviewer — it does not decide.

The bulk tool is a workflow system rather than a script: batches are uploaded, slices assigned to team members, progress on long-running runs streams live to the browser, and failed operations are tracked and retried without re-running the batch.

An agent platform for the same operations work, built around a hand-written tool-calling runtime — the agent picks the work up itself.

The progression is the story. The Hub proved the tooling could exist; it still needed a human to open it, feed it and drive it. The Agent removes that: work arrives, and the agent takes it end to end. Sessions enter through four surfaces — chat, a Jira issue, a Slack thread, or a schedule — into one runtime; a session doesn't care where it came from. Around 48 domain tools are available, and invokable skills loaded at runtime carry the domain instructions and unlock the tools each job needs, so a session's write access is defined by which skills it holds.

Every turn also writes an immutable, cache-aware cost record in nano-USD, so the cost per ticket is an exact number rather than an estimate. 103 test files and 10 database tables underneath.

Around 300 GraphQL operations, within reach of AI agents across the company — as four tools rather than 300.

The team that owns the graph brought me in for my agent engineering and LLM knowledge. I designed the tool schema and steered the design decisions; I wrote none of the server's production code. A design consult on someone else's production system is the honest description — and it's the part that made the difference.

One tool per operation would spend the whole context window on a menu before the agent does any work. So the surface is a discovery chain — list the operations, ask what one is for, introspect its schema, execute — and the graph can keep growing without the tool surface growing with it. Business context is its own step, because an operation name tells a model almost nothing about whether it's the right one; a dedicated step answers that in domain terms.

It runs in production today, and employees reach those services from their own agent applications.