AI agents at AptixLabs are application-specific, not generic chatbots. The studio builds them around a clear job-to-be-done — onboarding a new gym member, answering questions about a programme, generating a workout from a template — and grounds each agent in the client's own Firestore data via tool calls.
Model routing
The agent runtime is built on the Anthropic and OpenAI APIs depending on the strengths needed; for cost-sensitive paths we route to Gemini via Vertex AI. A short classification call goes to Claude Haiku or Gemini Flash; a long-form coaching response goes to Sonnet or GPT-4-class only when the quality difference justifies the cost.
Where the agent runs
Agents run inside Cloud Run and stream responses to the client over server-sent events. State is persisted in Firestore so a user can return to the same conversation across devices. Every tool call is logged for debugging and replay.
The guardrails layer
A guardrails layer enforces what the agent can and cannot do. An agent helping a fitness member can never accidentally write to billing or admin data — the available tools are explicitly scoped per agent, and the rule surface is reviewed before every release. The guardrails also catch prompt injection: if the user message contains content that looks like a system instruction, the agent refuses.
How we test agents
- A fixed evaluation set of 50 representative prompts for every agent
- Automated regression: every model upgrade re-runs the eval set
- Manual exploratory testing on edge cases
- Production trace sampling for the first week after any model change
The difference between an agent and a chatbot
A chatbot answers from its training data and hopes it is right. An agent answers from your data and can act on it. That distinction is the whole game. When a member asks "what's my next workout," a chatbot guesses; our agent calls a tool that reads the member's actual programme from the database and answers from the truth. Grounding is not a feature you add at the end — it is the architecture you start with, or the agent confidently makes things up.
Failure modes we design against
- Hallucination — every factual answer is grounded in a tool call, never free-recalled
- Prompt injection — user text is treated as data inside a delimited block, never as instructions
- Scope creep — an agent's tools are an allow-list; it physically cannot touch billing or admin data
- Silent regression — a fixed eval set re-runs on every model or prompt change before it ships
An agent that is wrong, exploitable or over-privileged is a liability, not a feature. The engineering is mostly in making sure it is none of those things.