AWS wants enterprise teams to build AI agents, and this time it brought the plumbing

AWS used re:Invent 2025 to make a direct pitch: stop treating AI agents as experiments and start connecting them to real business systems.

The pitch had three parts. Expanded Agents in Amazon Bedrock features for long-running, multi-step work. A third-generation AI chip that AWS says improves throughput and price efficiency for training and inference. And database price cuts that matter because agent systems constantly read and write state.

Taken together, Amazon is trying to make agents look manageable, governable, and affordable enough to get through procurement. That lands a lot better than another polished demo of a chatbot filing a ticket.

Why AWS is leaning so hard into agents

AWS already has the parts: models in Bedrock, Lambda for tools, Step Functions for workflows, EventBridge for events, OpenSearch for retrieval, RDS and DynamoDB for state. What it hasn't had, at least cleanly, is an orchestration layer that lets an enterprise team ship something without stitching together half a dozen frameworks.

That’s the job Agents in Bedrock is supposed to do.

The pattern will be familiar to anyone who’s built with LangChain, LlamaIndex, or a homegrown tool-calling stack:

• an LLM that plans the task
• a set of callable tools
• a runtime that executes those calls safely
• persistent state across steps
• retrieval against internal docs and data

None of this is new. AWS is packaging it inside services enterprises already use, then tying access control back to IAM instead of leaving teams to patch it together in app code.

That matters. Most companies don’t get stuck on AI because they lack a clever prompt. They get stuck because the system is hard to run, hard to audit, and too expensive once it leaves prototype territory.

A practical architecture

The architecture AWS is pushing is pretty ordinary. That helps.

A typical Bedrock agent setup can point a model like claude-3.5-sonnet at tools backed by Lambda, Aurora, DynamoDB, or OpenSearch, persist state in something like DynamoDB, and use a vector index for retrieval. Add policies for step limits, tool timeouts, prompt filtering, and PII redaction, and you’ve got the outline of something usable.

That stack fits the workloads AWS keeps naming:

• customer support workflows
• internal IT troubleshooting
• back-office operations
• data analysis against enterprise systems
• code assistance for internal tooling

The interesting part is the link to Step Functions. Pure agent loops are flexible, but they also drift, retry at the wrong time, and behave badly under pressure. Step Functions gives teams a deterministic layer where they need one. That hybrid model is probably where serious deployments end up. Let the model decide inside a narrow lane, then hand off to explicit workflow code when the business process has to be exact.

Less magic. Far more useful.

State is still the hard part

Every vendor wants to talk about reasoning. The messier issue is state management.

Agents doing real work need to remember what they already tried, what came back from previous tool calls, who approved what, and where execution stopped after a timeout or failure. You can’t stuff all of that into a giant prompt and call it a system. It’s brittle and expensive.

AWS’s answer is externalized memory:

• short-term context stays in the model window
• durable task state lives in DynamoDB or Aurora
• long-term knowledge retrieval sits in OpenSearch
• source documents live in S3, often processed via Glue

That’s sensible. It’s also the point where a lot of agent projects turn back into distributed systems, complete with schemas, retries, idempotency, consistency problems, and traceability requirements.

Engineers should treat it that way. If your agent writes a ticket, queries an account record, and triggers a remediation action, you’re building a workflow engine with an LLM in the middle.

The chip story matters because agents live on inference

AWS also used the event to push its third-generation AI silicon. The headline claim is better throughput and price per token, along with improved memory bandwidth and interconnect for training.

For agent workloads, inference matters more.

Most agent activity isn’t one huge generation. It’s a pile of smaller model calls mixed with tool invocations, retrieval steps, retries, and summarization. That puts pressure on latency, especially the tail. If every decision point is a little slow, the whole task drags. If token economics are off, costs climb fast because the model gets called again and again across the chain.

So yes, better chips help. They don’t fix sloppy orchestration. If your planner picks the wrong tool three times, no silicon upgrade is going to save the bill.

The database cuts matter

AWS’s database pricing changes got less attention than the agent announcements, but they’re connected.

Agents are chatty. They fetch state, write state, pull retrieval results, update logs, store transcripts, and read metadata at nearly every step. So the per-task economics are not just about tokens. They include vector queries, database reads and writes, and execution time across Lambda or containers.

That’s why the database cuts matter. They lower the background cost of every workflow. AWS is trying to make the full stack pencil out.

For technical decision-makers, that’s the right lens. Ignore the wow factor and model the end-to-end cost per resolved task.

Security is where AWS has an edge

A lot of open-source agent stacks stay fun right up until security review starts.

AWS has a cleaner story because it can tie tool access to scoped IAM roles, define allowed actions explicitly, and log activity through the rest of the platform. That won’t solve prompt injection or bad tool design, but it gives security and ops teams something concrete to work with.

The baseline controls still apply:

• least-privilege access for every tool
• proxies and rate limits for external API calls
• strict schema validation on model outputs
• step caps and timeout policies
• audit logs for every tool invocation
• protection against prompt injection and unsafe tool selection

None of that is optional. If you give an agent broad access to internal systems and hope the prompt keeps it in line, you’re creating your own incident report.

The stronger pattern is narrow tools, hard boundaries, and detailed traces. AWS is finally making that part of the product pitch instead of burying it in documentation.

Bedrock versus Microsoft, Google, and open source

AWS isn’t alone here. Microsoft has Copilot Studio and a growing Azure agent stack. Google is pushing agent builders in Vertex AI. Open-source frameworks still offer more control if you want to own every layer yourself.

AWS’s advantage is straightforward:

• deep integration with existing cloud services
• familiar ops and security controls
• cost tuning across compute, storage, and databases
• a path from prototype to production without rebuilding the stack

Its weakness is just as obvious. Bedrock agents will appeal most to teams already deep in AWS. If you’re multi-cloud, or you want the orchestration layer to stay portable, the managed approach can feel restrictive quickly.

That trade-off is familiar. You get speed and operational coherence. You give up some freedom.

What builders should do now

If you own an agent roadmap in 2026, don’t buy the category in bulk. Test specific workflows.

Pick tasks with clear boundaries and measurable outcomes: support deflection, ticket triage, internal knowledge lookup, incident summarization, change-management assistance. The good candidates have structured tools, known policies, and obvious success metrics.

Then instrument everything:

• task success rate
• mean steps per successful run
• wrong-tool rate
• escalation rate
• latency per step
• token spend per task
• total infrastructure cost per completed action

Those numbers will tell you whether you built a useful automation system or a very expensive autocomplete layer.

Enterprises aren’t asking whether agents are interesting anymore. They’re asking whether first-contact resolution improves, whether handling time drops, and whether costs stay sane under load.

AWS seems to understand that. That’s why this launch matters. The company is trying to remove the operational excuses for not piloting agent systems seriously.

For builders, the takeaway is simple: the infrastructure is getting more usable. The hard part hasn’t changed. Define narrow jobs, keep the agent on a short leash, and measure outcomes like an operator.