Inside the serverless AI agents that drove a 12% revenue uplift for AgentFlo

Picture this. It's Friday afternoon. You just deployed a brand new autonomous sales agent for your e-commerce platform. You tested the system prompts. You told it to be polite, to stick to the catalog, and to protect your margins.

Five minutes into production, a user starts messing with the chat interface. They convince your agent that they're the regional manager, they're extremely upset, and they demand you sell them a two-thousand dollar TV for exactly one dollar to compensate for emotional distress. The agent apologizes, applies a custom one-hundred percent discount, and completes the checkout tool call.

If you rely on system prompts to protect your transactional functions, this is exactly what happens. Large language models are stochastic. They want to please the user.

To fix this, you have to stop treating the model as the absolute decider. You treat it purely as a proposer. The surrounding architecture dictates what actually executes.

Building with Deterministic Guardrails

AgentFlo recently detailed how they built their commercial AI agents using Amazon Bedrock AgentCore. What they built is a masterclass in defense in depth. They aggressively box the model in using deterministic policies and rigid state machines. The language model can suggest whatever it wants; the surrounding architecture dictates what actually executes.

So how do you safely expose transactional tools to an agent without risking hallucinated offers? You don't just hand the model a Python function and hope for the best. AgentFlo uses a strict three-layer guardrail system.

1. The Pre-Request Filter: Before the request even reaches the language model, it passes through an AWS Fargate layer. This filter handles authentication and strips out obvious prompt injections.

2. The Execution Layer: This is where the real defense happens. They use the AgentCore Gateway combined with Cedar policies. Cedar is an open-source policy language developed by AWS, designed for fine-grained, verifiable authorization decisions. When the language model processes a user message and decides it needs to apply a discount, it doesn't execute the code. It simply proposes the tool invocation. The AgentCore Gateway intercepts this proposal. It evaluates the requested action against a deterministic Cedar policy. This policy defines the maximum allowable discount based on hard business rules. This evaluation happens entirely outside of the model's reasoning loop. If the model proposes a fifty percent discount, but the Cedar policy is hardcoded to cap discounts at fifteen percent, the action fails immediately. The model can't bypass this. The rules don't live in its context window. They live in the infrastructure.

3. The Post-Turn Privacy Filter: A final layer screens the generated text before it ever reaches the user. It blocks unverified price claims and prevents inadvertent token disclosures.

The model is boxed in at the input, at the execution boundary, and at the output.

Managing Multi-Day, Stateful Conversations

Commerce is highly stateful. A customer might ask a detailed question about a product on Tuesday morning, pause the conversation, and then come back on Friday night to finish the purchase. How do you manage a context window when an interaction pauses for three days?

You don't keep the session alive in active memory. You don't dump their entire history into a massive prompt. AgentFlo handles this with a rigid, two-table DynamoDB setup. They split the state into a Session table and a Cart table.

When a user returns after three days, the AgentCore runtime wakes up a dedicated microVM. It hits the DynamoDB Session table and loads exactly the last fifteen messages into the context window for the new turn. It provides just enough history to resume the chat without wasting tokens.

The Cart table is handled differently. It's loaded strictly on-demand. The agent only gets access to the current cart state if a deterministic intent detection system flags the user's incoming message as cart-related. Think about why that matters. If the user is just asking about your return policy, the cart data is hidden. The model doesn't know what's in the cart, and it doesn't know the prices. If the model doesn't have pricing and quantity data in its active context, it literally can't hallucinate a different price. It's aggressive state management designed to restrict what the model knows at any given microsecond.

The Friction: Complexity and Lock-In

Building agents this way is incredibly secure, but the adoption friction is steep. If you're used to spinning up application-level frameworks like LangGraph or the Vercel AI SDK on standard containers, this architecture will feel heavy. You aren't just calling a software kit. You're wiring up IAM roles. You're writing Cedar policies. You're configuring Bedrock Guardrails, DynamoDB tables, and AgentCore Gateway connectors.

Because the orchestration loop is locked entirely inside proprietary AWS infrastructure, stepping through the agent's thought process locally on your laptop is difficult. You also have to consider the latency and token penalty. Running every single request through a pre-turn Fargate filter, a mid-turn Cedar evaluation, and a post-turn privacy screen adds processing time. Furthermore, Fargate and DynamoDB might scale automatically during a massive flash-sale spike, but Foundation Model APIs have strict rate limits. Tokens per minute matter. You still have to do serious capacity planning.

If you're building an internal read-only bot, or if you require the flexibility to move your workloads from AWS to Azure next month, you should skip this pattern. The vendor lock-in is absolute. But if your agents are executing financial transactions or modifying active e-commerce carts, VPC-level network isolation and deterministic policy enforcement are non-negotiable.

The Shift to Server-Side Tool Execution

This brings us to the most significant architectural shift in the setup: AgentFlo is moving toward server-side tool execution. To understand why this matters, look at how we normally write client-side orchestration loops.

Right now, your application code sits between the user and the model. You send a prompt. The model decides it needs to call a tool, so it halts generation and sends a JSON payload back to your client. Your application parses that JSON, executes the local Python function, captures the result, formats it, and sends it back to the model to resume thinking. You write fragile while loops to manage this back-and-forth communication.

Server-side tool execution replaces all of that with a single API call. AgentFlo uses the Amazon Bedrock Responses API combined with the Model Context Protocol, or MCP. Instead of passing tool schemas in your prompt, you hand Bedrock an AgentCore Gateway Amazon Resource Name. That string acts as your MCP connector.

When you send the user message, Bedrock takes over entirely. The model autonomously discovers the available tools from the Gateway. It picks the right one. It invokes it. It processes the result and feeds it back into its own reasoning loop. All of this happens inside the AWS backend environment. There are no roundtrips back to your client. Your client never sees the intermediate turns. It never handles the tool schemas. It never touches the database credentials.

For specialist agents executing short, focused loops, this yields roughly a thirty percent reduction in latency. A sequence that checks inventory, applies a discount, and updates a cart used to take fifty lines of Python orchestration. Now it takes one network request.

From Prompt Engineering to Infrastructure Engineering

This architecture doesn't eliminate the complexity of your system. It simply shifts it. The orchestration logic that used to live in your application code now lives in your infrastructure-as-code configuration. You manage it through Terraform instead of Python. Every new platform integration, whether it's a payment processor or a shipping provider, just becomes another MCP server connector in the Gateway. It keeps expansion highly modular.

This architecture teaches us exactly where enterprise AI is heading. We spent a long time trying to make foundation models smarter. We tried to write the perfect system prompt so the agent would behave perfectly every time. This approach admits that's a flawed strategy.

You use the language model for what it's actually good at. You let it parse messy, natural human language. You let it handle fuzzy intent. You let it figure out that asking for the chocolate with the golden wrapper means a specific SKU in your database. But you don't let it make the final decision.

You let rigid, boring infrastructure handle the rules. You lock your multi-day session state in DynamoDB. You lock your permissions in Cedar policies. You execute your tools server-side where the client can't interfere. You don't try to teach the model not to hallucinate a bad price. You build a box so structurally sound that a hallucination simply fails to execute.

This is TAKEYOURPILLS.TECH. Go ship something.