Blog

Why we're building AgentForge

Almost every team we talked to before starting Qxentrix had already built an AI agent that worked — in a notebook, in a Slack bot, in a weekend prototype. The model did what it was supposed to do. What stopped them from shipping it wasn't the agent's intelligence; it was everything around it.

Turning a working prompt into something you'd trust with real customer conversations means solving problems that have nothing to do with prompting: How do you version a prompt without breaking the integration that calls it? How do you retry a failed tool call without double-charging a customer? How do you know, six weeks later, why the agent gave a wrong answer at 2 a.m. on a Tuesday?

We built AgentForge to be the answer to those questions by default, not as something each team re-derives on their own. An agent created through AgentForge gets a versioned endpoint, session memory, guardrails, and full run tracing the moment it's deployed — the same way a database gets backups and connection pooling without you asking for them.

We're starting narrow: three agent archetypes — support, internal ops, and sales assistants — because we'd rather be excellent at the patterns we understand well than generic across everything an "agent" could mean. DocMind and TensorForge, the next two products in the Qxentrix line, extend the same foundation to document Q&A and model fine-tuning.

If you're mid-way through building an agent and hitting the infrastructure wall we just described, we'd like to talk to you — we're onboarding design partners directly right now.

How AgentForge uses Amazon Bedrock

We made a deliberate choice early on not to run our own model-serving infrastructure. Every inference call an AgentForge agent makes runs through Amazon Bedrock, and that decision shapes almost everything else about how the platform is built.

Model access without the operational burden

Bedrock gives us a single, consistent API surface across model providers, so an agent's model field in its config can point at different underlying models without AgentForge needing a separate integration for each one. When a customer wants to compare two models for the same agent, that's a config change, not a redeploy of our infrastructure.

Guardrails as a first-class primitive

Bedrock Guardrails let us attach content filtering, PII redaction, and topic restrictions to an agent as policy, evaluated on both the prompt and the response. We surface this directly as the guardrails field on an agent, and fire a webhook event any time a guardrail actually blocks or redacts something — so guardrails are visible, not a silent black box.

Orchestration sits in Lambda and Step Functions

Bedrock handles inference; the orchestration loop — deciding when to call a tool, waiting for the result, and resuming the model with that result — runs in AWS Lambda for single-step calls and Step Functions when an agent needs a multi-step tool-calling workflow. That split keeps our compute costs proportional to actual usage, with no idle GPU capacity to pay for between requests.

The net effect is that when Bedrock adds a new model or region, AgentForge customers get access to it without waiting on us to build new infrastructure — which is exactly the leverage we want from betting on managed AWS services from day one.

Our AI infrastructure philosophy

We keep coming back to one test when we decide what to build next: would this let an on-call engineer debug a production incident with a trace ID instead of a screenshot? If the answer is no, we haven't finished the feature.

• Explainable over magical. Every response an agent gives should be traceable to a specific model, prompt version, and set of tool calls. We're wary of anything that makes an agent's behavior harder to reconstruct after the fact.
• Managed AWS services over custom infrastructure. We don't run GPUs, vector databases, or queues we could instead get from Bedrock, OpenSearch, or Step Functions. That's not laziness — it's a bet that our customers benefit more from us building agent-specific primitives than from us reinventing infrastructure AWS already runs at a scale we couldn't match.
• Versioning is not optional. An agent in production is a dependency other systems rely on. It gets the same treatment as an API: versioned, rollback-able, and never silently changed underneath a caller.
• Small surface area, done well. We'd rather support three agent types extremely well than claim to support every conceivable use of "AI agent" and support none of them deeply.

This philosophy is why AgentForge looks more like a deployment platform than a prompting playground, and why DocMind and TensorForge — still in development — extend the same primitives (versioning, tracing, guardrails) instead of introducing new ones. Infrastructure earns trust by being predictable, not by being clever.