BuildAI Command

Inspiration

BuildAI is our platform for running AI agents under real governance not just chat wrapped around a model, but agents with memory, tools, policy, and human approval built in. When we saw the WebMCP Challenge, the fit was obvious: our whole product thesis is that AI shouldn't act alone on anything risky. WebMCP let us test that thesis in the browser itself could ChatGPT operate our platform the same way a human does, approvals and all, without a custom integration?

What it does

BuildAI Command is a governed agent dashboard with three panels:

Agents — see your AI workers and run them on a task
Activity — watch runs progress in real time
Approvals — approve or reject sensitive actions before they execute (e.g. sending an email)

The same actions are exposed as WebMCP tools on the page, so an AI agent in ChatGPT's in-app browser can list agents, start a run, check status, and approve a step using the exact same governed path a human would. Say "run the support agent and approve the email if it looks right," and the agent and the platform work together on one screen.

How we built it

We kept scope deliberately narrow: one screen, one demo flow, our existing BuildAI backend doing the real work. The frontend is a thin client that calls our existing agents/runs/approvals API, with document.modelContext.registerTool() wiring each panel action run, status check, approve/reject into a WebMCP tool an agent can call directly. No new backend, no new auth model: we exposed what already existed, deliberately, as agent-callable tools.

Challenges we ran into

The main challenge wasn't the API integration. it was deciding what an agent should be allowed to do without asking. We didn't want WebMCP to become a backdoor around our own approval gate, so every sensitive action still routes through the same approvals queue whether a human or an agent triggered it. Getting that consistent one governance path, two callers took more design thought than the tool registration itself. Testing reliably in ChatGPT's in-app browser vs. Chrome's WebMCP flag also meant double-checking tool behavior in both environments before we trusted the demo.

What we learned

WebMCP is at its best when it exposes real actions with real consequences, not just read-only lookups. Building governance into the tool layer itself rather than trusting the agent to behave is what made this feel like a genuine agent-native product decision rather than a tech demo.