Seu agent tem 10 tools (AWS prova que precisa 100+)

Seu agent tem 10 tools (AWS prova que precisa 100+)

What just happened (October 2026):

AWS released:

"Agent Registry: Runtime tool discovery (agents find right tool automatically)."

"Problem solved: Hardcoded tools break at scale (5-10 tools = OK, 50+ tools = chaos)."

"New capability: Agents adapt to new tools without code changes (zero redeploy)."

What this means for your company:

Current situation (hardcoded tools): Your agent: Support chatbot Tools: 8 hardcoded 1. Get order status 2. Process refund 3. Check inventory 4. Send email 5. Create ticket 6. Lookup customer 7. Apply discount 8. Check warranty

Reality (after 6 months): New requirement: Track shipping (tool #9) Solution: Add tool to prompt Result: Agent confused (too many tools to choose from) Cost: Agent spends 50% tokens choosing tool (instead of reasoning)

New requirement: Check billing
Solution: Add tool #10
Result: Agent even more confused
Latency: Doubled (agent slower)
Accuracy: Dropped (wrong tool chosen)

New requirement: Process warranty claim
Solution: Add tool #11
Result: Chaos
  Agent can't choose right tool
  Customers get wrong answers
  Support team overwhelmed
  You restart: "Agent failed, remove it"

Problem: ✗ Hardcoding tools = inflexible (code change for every new tool) ✗ Agent confusion = accuracy drops (wrong tool chosen) ✗ Token waste = slow (agent spends tokens listing tools) ✗ Unscalable = breaks at 50+ tools (typical enterprise has 100+) ✗ Maintenance nightmare = each new tool = code review, test, deploy

After (AWS Agent Registry): Your agent: Same support chatbot Tools: Discovered at runtime (no hardcoding) Agent asks: "What tools are available for this request?" Registry responds: "Here are relevant tools: [list]" Agent chooses: Right tool (because list is curated, not overwhelming) Result: Accurate, fast, no hardcoding

Reality (after 6 months): New requirement: Track shipping Solution: Register tool in Agent Registry (no code change) Result: Agent automatically discovers it Cost: Zero redeploy, zero testing, zero risk

New requirement: Check billing
Solution: Register tool (same process)
Result: Agent uses it immediately

New requirement: Process warranty
Solution: Register tool
Result: Works instantly

Benefit: ✓ Flexible: Add tool anytime (no code change) ✓ Accurate: Agent gets curated list (not all 100 tools) ✓ Fast: Agent doesn't waste tokens (focused tool list) ✓ Scalable: Handles 100+ tools (enterprise-ready) ✓ Maintenance: Zero overhead (registry handles it)

---

The hardcoded tool problem (why it breaks)

The scaling curve

Reality of hardcoded tools:

Phase 1: 5-10 tools (works fine) Agent prompt: "You have these tools: [5-10 listed]" Tokens spent on tool description: 50-100 tokens Agent reasoning tokens: 400-450 tokens (out of 500) Accuracy: 95% (agent chooses right tool) Latency: 200ms (fast) Setup: Easy (hardcode 10 tools)

Example: User: "I want to return this product" Agent: "I have tools: refund, ticket, inventory..." Agent chooses: Refund tool (correct) Result: Handled perfectly

Phase 2: 20-50 tools (starting to degrade) Agent prompt: "You have these tools: [20-50 listed]" Tokens spent on tool description: 300-400 tokens Agent reasoning tokens: 100-200 tokens (out of 500) Accuracy: 70% (agent confused, picks wrong tool) Latency: 800ms (slower, agent spends time choosing) Setup: Painful (hardcode 50 tools, maintain list)

Example: User: "I want to return this product" Agent: "I have 50 tools: refund, ticket, inventory, billing..." Agent confused: "Which tool should I use?" Agent chooses: Wrong tool (e.g., billing instead of refund) Result: Handled incorrectly Customer: "Your agent is useless"

Phase 3: 100+ tools (completely broken) Agent prompt: "You have these tools: [100+ listed]" Tokens spent on tool description: 800-1000 tokens Agent reasoning tokens: -300 tokens (exceeds context!) Accuracy: 20% (agent randomly chooses) Latency: 5+ seconds (agent times out trying to choose) Setup: Impossible (hardcode 100 tools, maintain, test)

Example: User: "I want to return this product" Agent: Timeout (can't fit all tools in context) OR Agent: "I don't know which tool to use" Result: Agent fails completely Customer: "Your agent is broken, speak to human"

Conclusion: 5-10 tools: Hardcoding works 20-50 tools: Hardcoding struggles 100+ tools: Hardcoding fails

Enterprise reality: 100-200+ internal APIs Your hardcoded agent: Completely broken at scale

Why enterprises have 100+ tools

Typical enterprise system:

Orders system:

• Create order
• Update order
• Cancel order
• Get order status
• Get order history
• Apply discount
• Generate invoice
• Track shipment Total: 8 tools

Customer system:

• Lookup customer
• Update customer info
• Get customer history
• Get customer preferences
• Set billing address
• Set shipping address
• Add loyalty points
• Get account balance Total: 8 tools

Inventory system:

• Check stock
• Update stock
• Get warehouse location
• Get product info
• Check availability
• Pre-order Total: 6 tools

Billing system:

• Get invoice
• Process refund
• Apply payment
• Check account
• Get billing history
• Set payment method Total: 6 tools

Support system:

• Create ticket
• Update ticket
• Assign ticket
• Close ticket
• Get SLA
• Escalate Total: 6 tools

Shipping system:

• Create shipment
• Track shipment
• Get rates
• Print label
• Schedule pickup Total: 5 tools

Analytics system:

• Get sales report
• Get customer report
• Get inventory report
• Get support report
• Export data Total: 5 tools

Total: 44 tools (just core systems)

Add:

• Email system (3 tools)
• SMS system (2 tools)
• CRM system (8 tools)
• Marketing automation (6 tools)
• Compliance system (5 tools)
• Internal knowledge base (4 tools)
• Partner APIs (10 tools)
• Legacy systems (20 tools)

Total: 100+ tools (realistic)

Your hardcoded agent: Can handle 5-10, breaks at 100 Enterprise agent: Needs to handle 100+

---

The solution: Runtime tool discovery

How AWS Agent Registry works

The mechanism:

Old approach (hardcoded): Agent prompt: "You have these 10 tools: [list]" User query: "Help with my order" Agent: Chooses from hardcoded list (10 options) Problem: Doesn't scale

New approach (runtime discovery): Step 1: User query: "Help with my order" Step 2: Agent asks: "What tools are available for 'order' queries?" Step 3: Agent Registry responds: "Available tools for orders: [create, status, refund, track]" Step 4: Agent receives curated list (4 tools, not 100) Step 5: Agent chooses from relevant subset (high accuracy) Step 6: Tool executes, user gets answer

Benefit: Agent only sees relevant tools (context stays small) Result: Fast, accurate, no hardcoding

How it works technically: Agent Registry (central catalog): Stores: All available tools + metadata Metadata: Tool name, description, category, input params

Agent query: "What tools help with [category]?" OR "What tools match [keywords]?" OR "What tools can [action]?"

Registry response: Returns relevant tools (filtered, not all) Agent gets manageable list (5-10, not 100)

Agent reasoning: Chooses best tool from curated list Accuracy: High (fewer options to confuse) Speed: Fast (less token overhead)

Example: User: "I want to return this order #12345" Agent asks registry: "Tools for returns?" Registry: "Available: [Process refund, Create return ticket, Get return status]" Agent: "I'll use Process refund (best match)" Agent executes tool User: "Refund processed" (correct!)

Benefits over hardcoding

Comparison:

Hardcoded tools: ✗ Fixed at deployment (can't add tool without redeploy) ✗ All-or-nothing (agent sees all tools or none) ✗ Token waste (agent lists all tools in prompt) ✗ Accuracy degrades (too many choices = wrong tool) ✗ Latency increases (agent spends time choosing) ✗ Maintenance hell (update code, test, deploy for each tool) ✗ No metadata (agent doesn't know tool purpose) ✗ No governance (no control over tool access)

Runtime discovery (Agent Registry): ✓ Dynamic (add tool anytime, no redeploy) ✓ Contextual (agent gets relevant tools only) ✓ Efficient (no token waste on irrelevant tools) ✓ Accurate (small choice set = right tool) ✓ Fast (agent decides quickly) ✓ No maintenance (registry handles tools) ✓ Rich metadata (agent understands tool purpose) ✓ Governance (control who accesses what tool)

Example numbers: Scenario: 100 total tools, but user query only needs 5

Hardcoded approach: Agent prompt size: 3-4 KB (all 100 tools listed) Tokens spent on tools: 800 tokens Agent reasoning tokens: -300 (context overflow!) Result: Agent fails

Registry approach: Agent prompt size: 200 bytes (5 relevant tools) Tokens spent on tools: 50 tokens Agent reasoning tokens: 450 tokens Result: Agent succeeds

---

Real-world scenarios (when tool discovery matters)

Scenario 1: Enterprise support agent

Problem:

Company: E-commerce (Shopify-like) Customers: 100k Internal APIs: 120 Agent tools: Currently hardcoded to 8 (biggest ones)

Customer queries:

• "Track my order" (5 tools needed)
• "Refund my order" (8 tools needed)
• "Update my address" (6 tools needed)
• "Check inventory" (4 tools needed)
• "Schedule return" (7 tools needed)

Each query needs different tools Hardcoding: Only 8 tools total → 70% of queries fail

With Agent Registry: Each query → Registry returns relevant tools Agent success rate: 95%+ Customer satisfaction: Increases Support costs: Decrease (fewer escalations)

ROI: Current: Hardcoded agent handles 30% of queries (fails on 70%) With registry: Agent handles 95% of queries Cost savings: +65% more queries automated Annual impact: $500k+ (fewer support agents needed)

Scenario 2: Sales agent (internal)

Problem:

Company: SaaS (CRM user) Internal systems: 8

• Salesforce (CRM)
• Stripe (billing)
• Slack (messaging)
• Jira (tickets)
• Google Workspace (docs)
• GitHub (code)
• Mixpanel (analytics)
• Zendesk (support)

Agent tools: 5 hardcoded

• Get customer info (Salesforce)
• Check subscription (Stripe)
• Post update (Slack)
• Create issue (Jira)
• Get analytics (Mixpanel)

Missing tools:

• Access docs (Google)
• Check code (GitHub)
• Get support history (Zendesk)

Problem: Sales rep asks "What's the customer's support history?" Agent: "I don't have that tool" Rep: "Your agent is useless"

With Agent Registry: Add Zendesk tool (register in registry, no code change) Same query: Agent discovers Zendesk tool Rep: "Great! Agent has it now"

Benefit: Deploy new tool in minutes, not weeks

Scenario 3: Workflow automation (supply chain)

Problem:

Company: Logistics (100+ warehouse locations) External APIs: 50+ (suppliers, carriers, customs, analytics) Internal APIs: 30+ (inventory, billing, compliance) Total: 80+ tools

Agent job: Automate supply chain workflows

• Check supplier inventory
• Compare prices
• Book shipment
• Track in-transit
• Manage customs
• Pay invoice
• Update forecast

Hardcoded approach: Impossible

• Can't hardcode 80 tools (agent breaks)
• Can't update for new supplier (code change needed)
• Can't adapt to new workflow (redeploy needed)

With Agent Registry:

• Register all 80 tools once
• Agent queries: "Tools for [workflow]?"
• Registry returns relevant tools (auto-curated)
• Agent executes workflow
• Add new supplier: Register tool (no code change)
• Result: Scalable, flexible, maintainable

Benefit: Automate complex workflows across 100+ suppliers

---

How to implement tool discovery (practical steps)

Step 1: Inventory your tools

What to do:

List all APIs/tools your agent needs:

1. Internal APIs (your systems)
2. SaaS APIs (Salesforce, Stripe, etc.)
3. External APIs (suppliers, partners)
4. Custom tools (internal scripts)

Example inventory: Tool ID: order-create Name: Create Order Category: Orders Description: Creates new customer order Input: customer_id, items, address Output: order_id, status

Tool ID: refund-process Name: Process Refund Category: Billing Description: Processes refund for order Input: order_id, amount Output: refund_id, status

[... repeat for all tools]

Target: Document all tools (even ones not used yet) Timeline: 1-2 days (internal audit)

Step 2: Organize tools by category

Categorization:

Categories:

• Orders (create, update, cancel, status, track)
• Billing (refund, invoice, payment, balance)
• Inventory (check, update, warehouse)
• Shipping (create, track, rates)
• Support (ticket, escalate, resolve)
• Customer (lookup, update, preferences)
• Analytics (reports, export, dashboard)
• Integration (external APIs)

Benefit: Agent can query by category "Tools for refund?" → Returns Billing category tools Agent picks best tool from curated list Result: Accurate, fast

Timeline: 1 day

Step 3: Implement Agent Registry (choose platform)

Options:

Option 1: AWS Agent Registry Pros: Native to AWS, integrates with Bedrock Cons: AWS-only (vendor lock-in) Cost: Included with Bedrock Timeline: 1 week to full implementation

Option 2: Open-source (build your own) Pros: No vendor lock-in, fully customizable Cons: More work to implement Cost: Engineering time ($5-10k) Timeline: 2-4 weeks

Option 3: Third-party registry service Pros: Standardized, vendor-agnostic Cons: New tool (emerging) Cost: $500-5k/month Timeline: 1 week

Recommendation: Start with AWS Agent Registry (fastest) If you outgrow it: Migrate to open-source (flexible)

Timeline: 1 week to MVP

Step 4: Deploy and test

Testing:

Test scenarios:

1. Agent queries registry: "Tools for order refund?" Expected: Registry returns relevant tools (refund, ticket, etc.)

2. Agent chooses tool: Processes refund Expected: Refund executes correctly

3. New tool added: Zendesk support tool registered Expected: Agent discovers it without redeploy

4. At scale: 50+ tools registered Expected: Agent still accurate (registry filters tools)

Success metrics: ✓ Agent accuracy > 90% (right tool chosen) ✓ Latency < 500ms (fast tool selection) ✓ New tool deployment: 0 redeploy (automatic discovery) ✓ Scalability: 100+ tools (no degradation)

Timeline: 1 week of testing

---

The competitive advantage

Market position

Companies that implement tool discovery:

Will have: ✓ Scalable agents (100+ tools, no problem) ✓ Fast deployment (new tool = 5 min, not 1 week) ✓ Flexible agents (adapt to new workflows instantly) ✓ Higher accuracy (agent chooses from curated list) ✓ Better customer experience (agents handle more queries)

Will not have: ✗ Hardcoded tool limits (5-10 tools max) ✗ Slow deployment (code change → test → deploy) ✗ Inflexible agents (can't adapt) ✗ Lower accuracy (agent confused by too many tools) ✗ Customer frustration (agent fails on complex queries)

Market timing: Early movers (now, 2026): 6-12 month advantage - Deploy agents 10x faster - Automation 2-3x higher coverage - Customer experience 2x better

Late movers (2027+): No advantage - Everyone has tool discovery - Becomes table-stakes - Cost competition begins

Never movers: Dead - Stuck with hardcoded tools - Can't scale agents - Agents become liability (poor UX)

---

Conclusion: Tool discovery is mandatory at scale

Summary:

What changed: AWS released Agent Registry (runtime tool discovery) Implication: Hardcoded tools are now obsolete Reality: Enterprise agents need 100+ tools, not 10

Why it matters: Your hardcoded agent: Works with 5-10 tools Enterprise reality: Needs 100+ tools Result: Your agent doesn't scale

What to do: Week 1: Inventory all tools (what APIs do you have?) Week 2: Organize by category (group related tools) Week 3: Implement Agent Registry (AWS or custom) Week 4: Deploy and test (ensure accuracy >90%) Week 5+: Add new tools (auto-discovered, no redeploy)

Timeline: 1 month to production Cost: $5-50k (depends on platform) Benefit: Agent handles 3-5x more queries ROI: 10-50x (depending on use case)

Bottom line: Hardcoded tools = works for small agents (5-10 tools) Runtime discovery = works for enterprise agents (100+ tools) Your choice: Scale now, or rebuild later (expensive)

Question: Does your agent have 100+ tools available?

→ OpenClaw: AWS Agent Registry integration, runtime tool discovery, agent scalability, tool orchestration, enterprise agent architecture, dynamic tool selection

Seu agent tem 10 tools. Empresa precisa 100+. Agent Registry = descoberta automática. Zero redeploy. 🔧✨✅