AI agents are supposed to save engineering time.
In practice, many agents work for too long, burn too many tokens, and still return weak results.
The usual reaction is to improve the prompt. Add more instructions, architecture documentation, examples, and exceptions. Eventually the system prompt becomes a small internal wiki.
This does not solve the main problem.
Agents often spend most of their time rediscovering context they should already have and trying to work through interfaces that were not designed for them.
The Real Cost Is Rediscovery Link to heading
Consider a simple question:
Why did our AWS cost increase this week?
Without tools and company context, an agent may need to:
- discover the available AWS accounts
- find the billing data
- inspect multiple services
- search Terraform repositories
- guess resource ownership
- compare metrics manually
- retry commands with different parameters
Every step adds more output to the conversation. The model must process that output again during later steps.
The result is a compounding loop:
Missing context → more discovery → larger context window → slower reasoning → more tokens
The agent may eventually find the answer. But the path is expensive, slow, and difficult to reproduce.
Bigger Prompts Are Not Operational Context Link to heading
Prompts are useful for defining goals and constraints:
- operate read-only
- do not expose customer data
- explain the evidence
- request approval before making changes
These are good instructions.
But a prompt cannot contain the current state of AWS. It cannot know that an RDS instance changed yesterday, which team owns it, why it is intentionally oversized, or whether a Reserved Instance affects the resizing decision.
Adding more static text does not fix dynamic information.
Large prompts can also make the problem worse. Old information stays after systems change, unrelated context competes for attention, and every request pays to process the same text again.
A prompt should explain how the agent works. It should not contain everything the agent may ever need.
Context Reduces Repeated Discovery Link to heading
Context gives operational meaning to raw AWS data.
Useful context includes:
- AWS account and environment ownership
- application-to-resource relationships
- architecture decisions
- previous incidents
- known exceptions
- security requirements
- planned changes
This does not need to be loaded into every prompt. It should be searchable and retrieved when relevant.
An agent investigating an RDS cost increase may need database ownership, recent resizing plans, and Reserved Instance commitments. It probably does not need Kubernetes documentation or last year’s CloudFront incident.
Good context is selected, not dumped.
Tools Ground Agents in Reality Link to heading
Context explains the environment. Tools provide current evidence and controlled actions.
For AWS operations, useful tools can expose:
- Cost and Usage Report queries
- AWS Resource Explorer searches
- CloudTrail event lookup
- AWS Config history
- CloudWatch metrics
- AWS Health events
- resource ownership data
A focused tool can replace thousands of tokens of exploration.
Instead of asking an agent to discover where billing data lives and construct a query, provide one tool that accepts an account, service, date range, and grouping. The tool can validate the request, run the approved query, filter irrelevant data, and return a small structured result.
The agent can then spend tokens reasoning about the answer instead of discovering how to obtain it.
MCP can provide a standard interface for these tools. But MCP does not make a bad tool good.
Tools Must Be Narrow Link to heading
Giving an agent generic shell access does not automatically make it efficient.
A poorly designed tool may return thousands of resources, complete log files, or unfiltered API responses. That only moves the token problem.
Good agent tools should:
- accept explicit parameters
- filter data before returning it
- return structured results
- enforce output limits
- expose clear errors
- separate reads from writes
- avoid returning secrets
- record invocation metadata
The best tool does one operational job well.
Security Boundaries Still Apply Link to heading
AI does not change the AWS security model.
Agents should use the same controls expected from any production workload:
- least-privilege IAM roles
- temporary STS credentials
- separate permissions for reading and mutation
- explicit account and environment boundaries
- human approval for sensitive actions
- audit logs for every tool call
Read-only access should be the default.
An agent investigating cost does not need permission to resize RDS. If it recommends a change, that action should pass through a separate approval and execution path.
Prompt instructions such as “never change production” are useful, but they are not security controls.
IAM and tool boundaries are controls.
Measure Completed Work Link to heading
A long agent trace may look productive while hiding a lot of waste.
I would measure:
- tokens per completed task
- time to first useful result
- number of tool calls
- repeated reads and queries
- failed tool attempts
- human corrections required
The objective is not to minimize every token. Complex tasks still require exploration.
The objective is to stop paying repeatedly for predictable discovery work.
Final Thoughts Link to heading
Better prompts matter. Better models matter too.
But neither replaces current information, company context, or safe operational interfaces.
For production AI agents on AWS:
- prompts define goals and constraints
- context explains the environment
- tools retrieve evidence and perform controlled actions
- IAM defines what is actually allowed
- humans approve high-impact decisions
The fastest agent is not the one with the largest prompt.
It is the one that knows where to look, has the right tool, and stops when the job is complete.