Skip to content

AgentHub Studio

One interface. Several specialised systems. An orchestration layer deciding what happens next.

Role
Sole designer and engineer
Year
2026
Type
Agentic workspace · MVP
Stack
  • Python
  • FastAPI
  • OpenAI API
  • LangChain
  • LangGraph
  • SQLite
  • ChromaDB
  • Google OAuth
  • Google APIs
  • HTML
  • CSS
  • JavaScript

Architecture

Dashed — considered, not selected
07/07Compose answer
REQUESTEmail the team our top accountsROUTERROUTERintent → capabilitySQLSQLsqlite · parameterisedRETRIEVALchromadbGMAILGMAILgoogle apiCALENDARgoogle apiGATEGATEhuman in the loopAWAITING APPROVALAPPROVED BY HUMANRESPONSEDraft ready. Awaiting your send.

The interesting problem was never the integrations. It was deciding, per request, which capability should run — and where a human has to stay in the loop.

Overview

AgentHub Studio is a local workspace where one conversational surface sits in front of several unrelated capabilities: a SQL database, a document index, and a set of external service integrations including Gmail, Google Calendar, Google Drive, and GitHub.

It is an MVP built to explore a single question rather than to ship as a product: if a user can ask for anything, what has to exist between the request and the capability that answers it?

The problem

Most LLM demos wire a model to one thing. The moment you attach several, the hard part moves. The model is no longer the bottleneck — the decision is.

A request like “what did we sell last quarter” needs schema-aware SQL. “What does the onboarding doc say about access” needs retrieval. “Send that to the team” needs a mail integration and, critically, needs to not send anything until a person has confirmed it. Those three requests look identical arriving at the interface.

How the system works

A request moves through an orchestration graph rather than a chain of if-statements. Each node can inspect the state accumulated so far and decide where control goes next.

  1. 01IntakeRequest enters through a single chat surface. No mode switching, no tool picker.
  2. 02RouteThe orchestration layer classifies intent and selects a capability, with the reasoning kept in state.
  3. 03ExecuteThe selected node runs: parameterised SQL, vector retrieval, or an authenticated API call.
  4. 04GateAnything with an external side effect stops here and waits for explicit human approval.
  5. 05RespondResults are composed back into a single natural-language answer with its source attached.

Technical decisions

Four choices shaped the build more than the rest.

  • Graph execution over a linear chain

    A LangGraph-style state machine, not a prompt chain. Routing becomes an explicit, inspectable edge rather than a behaviour buried in a system prompt, which makes wrong routes debuggable instead of mysterious.

  • An approval gate as a first-class node

    Sending mail, creating calendar events, and writing to a repository are gated. The gate is part of the graph, not a confirmation dialog bolted onto the UI, so a new integration cannot accidentally skip it.

  • Constrained SQL access

    The database node works from an introspected schema and generates parameterised, read-oriented queries against SQLite. The model proposes a query; it never gets a raw connection to do as it pleases.

  • Retrieval as one capability among many

    Documents live in ChromaDB and are reached through the same routing decision as everything else. RAG is a branch of the graph, not the architecture of the whole application.

Challenges

  • Ambiguous intent

    Plenty of real requests legitimately touch two capabilities. Getting the router to ask a clarifying question instead of confidently guessing was more work than adding any single integration.

  • OAuth across several Google scopes

    Gmail, Calendar, and Drive each need their own consent scope, and tokens have to be refreshed and stored without leaking into logs or prompt context.

  • Keeping state legible

    As nodes multiplied, the accumulated run state became the thing I debugged most. It pushed me toward treating observability as a feature rather than an afterthought.

Interface

Captures from the local workspace.

Capture to follow

What I learned

Agentic systems are mostly a control-flow problem wearing an AI costume. The model is a component; the architecture around it decides whether the thing is trustworthy.

I also learned to design for the moment the system is wrong. An approval gate, a visible route, and a cited source do more for user trust than a better prompt does.

Next project02

LangGraph SQL Agent

Natural language goes in. A stateful execution pipeline decides how to query the database safely.