Future Friday

Your Agents Are Waiting for Humans. That's the Bug.

Published May 15, 2026 — 6 min read

TL;DR: Most enterprise AI agents are built as request-response systems — they sit idle until a human pings them. That's not agentic, that's a chatbot with extra steps. The teams pulling real value from agents in 2026 have made a quiet architectural shift to event-driven design, and it changes everything about what an agent can actually do.

Key Insight

Here's the uncomfortable truth about most "AI agent" deployments: they're fundamentally passive. A human opens a chat window, types a request, the agent responds. Repeat. That's not autonomous intelligence — that's autocomplete with a personality.

The teams that have moved past POC purgatory and into production impact have rebuilt their agents around a different trigger model: events, not prompts.

In an event-driven agent architecture, an agent wakes up because something happened in the world — a support ticket was filed, a contract landed in a shared inbox, an inventory level crossed a threshold, a scheduled window opened. The agent doesn't wait to be asked. It acts.

This isn't a novel concept. It's how we've built reliable software for 20 years (message queues, webhooks, pub/sub). The contrarian point is that we keep building AI agents as if they're chat interfaces when they should be autonomous processes wired into the event streams that already exist in every enterprise.

Why Teams Miss This

The default mental model is inherited from demos and product marketing. Every AI agent demo shows a human typing a question and an agent responding. It's intuitive. It's legible. It's also the worst possible design for an agent that needs to handle thousands of events per day without a human in the loop for each one.

Teams then encounter a scaling problem: the agent is only as fast and consistent as the humans remembering to ask it things. You haven't automated the work — you've automated the response to a request about the work. That's one abstraction layer short of the actual win.

Three specific failure modes this creates:

  1. The "why didn't it catch that?" problem. Agent was never told about the edge case because no one thought to ask. An event-driven agent would have seen the same data and acted without needing the prompt.

2. The context collapse problem. By the time a human asks the agent to handle something, the relevant context (a Slack thread, a prior decision, a Jira ticket) has to be manually attached. An event-triggered agent has direct access to the event payload and its full origin context.

3. The throughput ceiling. Your best human operators can triage ~50 complex situations per day. An event-driven agent handles 50,000. The moment you make agents dependent on human triggers, you've capped their throughput at human speed.

How to Actually Do It

The core pattern: wire your agents into the same event bus your other systems use. Don't build a separate "AI interface" — embed agents as consumers in your existing event streams.

Basic pattern (AWS + Bedrock):

def lambda_handler(event, context):

# Event came from: S3 upload, Salesforce webhook, Jira status change, etc.

event_payload = event["detail"]

agent_response = bedrock_agent_runtime.invoke_agent(

agentId=AGENT_ID,

agentAliasId=ALIAS_ID,

sessionId=event_payload["entity_id"], # natural session scoping

inputText=build_prompt_from_event(event_payload)

)

# Agent acts, logs result, triggers downstream events if needed

route_agent_output(agent_response, event_payload)

The key decisions:

1. Use your existing event bus. If you're on AWS, EventBridge is already there. Kafka, SQS, Azure Service Bus — same principle. Don't build a custom "agent trigger" system; agents are just another consumer type.

2. Session scoping via entity ID. Each unique entity (customer, contract, ticket) gets its own session context. When the same customer triggers three events in a day, the agent maintains coherent context across all three without human re-briefing.

3. Idempotency is non-negotiable. Events can fire twice (network hiccups, retries). Your agent actions must be idempotent or gated behind deduplication checks. This is table stakes for event-driven systems — it applies equally to agents.

4. Human-in-the-loop as an output event, not an input requirement. When the agent hits a low-confidence decision, it fires a `HUMAN_REVIEW_REQUESTED` event with its reasoning and proposed action. A human reviews an async queue — not a blocking chat thread. This is how Salesforce Agentforce handles escalation in its service cloud deployments.

Real example from enterprise deployments: A financial services firm wired a compliance agent to their document management system via S3 event notifications. Every new contract upload triggers the agent, which classifies the document, flags compliance issues, routes it to the right review queue, and logs a structured audit record — all before a human ever opens the file. Throughput went from 200 docs/week (human-triaged) to 4,000 docs/week, with humans only reviewing the 8% that the agent flagged as ambiguous.

What We've Learned

If you're running a request-response agent in production, map out every time a human has to remember to involve it. Each one of those moments is an event trigger waiting to be wired up.

Start with the highest-frequency, most consistent trigger in your workflow. Replace the "remember to ask the agent" step with an automatic event. Measure the change in throughput and error rate over four weeks.

The agent doesn't get smarter. Your architecture does.

FAQ

Q: Won't event-driven agents run wild if there's no human in the loop?

A: Only if you skip the escalation event pattern. Build `HUMAN_REVIEW_REQUESTED` as a first-class output type, set confidence thresholds for autonomous action, and you get high throughput with appropriate human oversight — not instead of it.

Q: Do I need a different model for event-driven agents vs. chat agents?

A: No. The model is the same; what changes is how it's invoked and what context it receives. A well-structured event payload is often better context than a human prompt because it's structured, complete, and machine-generated.

Q: What about agents that need to poll for changes instead of receive events?

A: Polling is a fallback when webhooks aren't available (legacy systems, third-party APIs). Use scheduled EventBridge rules for polling agents, but design the agent logic identically — stateless, idempotent, event-aware. Treat the poll result as a synthetic event.

Q: How do we handle event storms — thousands of events firing at once?

A: Apply standard backpressure patterns: SQS with visibility timeout and DLQ, Kafka consumer group with controlled lag monitoring, or EventBridge pipes with batching. These are solved problems in distributed systems. Your agent doesn't need to know about them — your event infrastructure does.

Q: Is this different from what Salesforce Agentforce or Microsoft Copilot Studio does?

A: These platforms are moving in this direction, but they abstract away the event bus, which limits flexibility. Building on native event infrastructure (EventBridge, Kafka, Service Bus) gives you finer control over routing, filtering, and throughput — worth the complexity for high-volume enterprise use cases.

Q: What's the first event trigger to wire up if we're starting fresh?

A: Pick your highest-volume, most structured, most consistent business event. Support ticket creation, document upload, or CRM record status change are common starting points — all structured, all high-frequency, all currently requiring manual triage that an agent can handle.

Sources