Harsh Yadav.

The problem

GEOS clients manage legal entities across jurisdictions — entity status, compliance deadlines, document state, stakeholders. Day-to-day, “what’s the status of X?” meant clicking through three or four screens. Slow for them, expensive for us in support load.

A chatbot wrapper would have been the easy build: stick an LLM in a side panel, prompt it with some entity data, ship. Almost every B2B AI demo with that shape leaks across tenants the moment a question gets specific enough — and trust dies the first time a customer sees another customer’s data.

What mattered

• No new security surface. The platform already had a 5-layer tenant isolation model. The agent had to inherit it, not work around it.
• Auditable. Every model action had to be traceable to a specific user and a specific permission scope.
• Honest scope. B2B users tolerate “I don’t have access to that” much better than wrong answers delivered confidently.
• Shippable with our team size. Five engineers, bootstrapped. No room for a six-month spike on agent infra.

The bet

Route the agent through the platform’s existing API layer — not beside it.

The model doesn’t get database access. It calls a defined set of tools, and those tools call the same API endpoints the platform’s UI already uses. Whatever a logged-in user can see in the UI, the agent can see for them. Whatever they can’t see, the agent can’t either. RBAC, tenant isolation, audit trail — all inherited from a layer we’d already hardened.

The cut: free-form database access (faster to prototype, but a separate auth surface to maintain forever) and a standalone “AI service” with its own permission model (a permanent maintenance tax we couldn’t afford).

How I scoped the tool surface

The agent has tools, not a database. Each tool is a thin wrapper around an existing API endpoint:

• Read entity info, compliance status, stakeholders, documents — for entities the user has access to.
• Cannot query other clients’ data, perform admin operations, or reach anything outside the user’s permission scope.

I wrote the PRD with the tool surface as the core artifact, paired with engineering on the boundary checks, and paired with design on how answers render — citing sources, surfacing confidence, handling “I don’t know.”

What shipped

V1 went out as a product feature, not a chatbot. Tenant-isolated, RBAC-honoring, audit-logged. Clients started using it for the lookup work that used to mean three clicks. Support load on those question types dropped meaningfully even at V1 traffic.

The pattern travels: agent on top of existing APIs, not beside them. We didn’t build new infrastructure; we reused what worked.

What I’d do differently

Ship eval before scale. V1 didn’t have an explicit eval rubric — we caught regressions through manual spot-checks. Worked at low traffic; the moment we wanted to A/B prompt changes or upgrade models, we paid for that in catch-up. Next agent gets the rubric on day one.

Lock the answer-rendering contract earlier. The first design round let the model decide format. Customers wanted predictable structure (status pill, dates, source link) more than they wanted natural prose. Locking the rendering shape earlier would have saved iteration cycles.