Key facts.
- METR's time-horizon evaluations (arXiv:2503.14499) found that agents on tasks requiring long-horizon or asynchronous process management show substantially larger performance gaps versus human baseline than on synchronous, single-session tasks (METR, arXiv:2503.14499).
- Event-driven architectures where services communicate via message queues (Kafka, RabbitMQ, SQS) process requests asynchronously; a synchronous tool call to an event-driven system typically receives an "accepted" response with a job ID, not a result.
- Internal microservices at scale enterprises commonly use async patterns for operations that exceed 200ms processing time, meaning a significant portion of enterprise tool integrations are inherently async without the agent scaffolding team necessarily knowing.
- tau2-bench (arXiv:2506.07982) includes scenarios where agents must manage tool state across multiple turns, exposing the failure mode where agents lose track of async jobs started in earlier turns because they have no persistence mechanism for job IDs.
- Polling-based async wrappers, where the tool wrapper starts the async job and then polls a status endpoint until completion before returning to the agent, convert async systems to synchronous interfaces but introduce their own failure modes: polling timeouts, missed completion signals, and resource consumption during wait periods.
The three async integration patterns and their failure modes
METR shows reliability drops on async work; a more capable model times out on an event queue when the wrapper assumes sync REST. (arXiv:2503.14499)
Three patterns exist for bridging synchronous agent tool calls to async microservices, each with distinct failure modes. The first is polling: the tool wrapper submits the job, stores the job ID, and polls the status endpoint at intervals until completion or timeout. Failure mode: if the polling timeout is shorter than the job's processing time, the tool returns an incomplete result. If the polling interval is too short, the tool consumes excessive resources. The second is callback: the tool wrapper registers a callback URL and waits for the async system to notify on completion. Failure mode: if the callback is not received (network failure, misconfiguration), the tool hangs indefinitely. The third is fire-and-forget with deferred collection: the tool wrapper submits the job and returns immediately; a separate tool call collects the result when needed. Failure mode: the agent must track the job ID across turns, which most agent frameworks do not natively support.
What async-aware tool wrappers require
An async-aware tool wrapper needs four components that a synchronous wrapper does not. First, a job registry that persists job IDs across agent turns, not just within a single tool call. Second, a status polling or notification mechanism that checks job state without blocking the agent's context window. Third, a timeout and escalation path for jobs that exceed their expected completion window. Fourth, a result collection mechanism that the agent can invoke separately from the job submission, allowing the agent to continue other work while the async job processes.
Async wrapper pattern comparison
| Pattern | Agent experience | Primary failure mode | Best for |
|---|---|---|---|
| Polling wrapper | Blocking until result | Timeout shorter than job processing | Jobs under 30 seconds |
| Callback wrapper | Non-blocking, agent continues | Callback not received | Jobs with reliable delivery guarantees |
| Fire-and-collect | Non-blocking, manual collection | Agent loses job ID across turns | Long-running jobs, multi-session workflows |
| Webhook receiver | Non-blocking, event-driven response | Webhook delivery failure | Systems with native webhook support |
VibeModel's Pattern Intelligence Layer identifies which tool integrations in your deployment show the failure signatures of sync-wrapper-on-async-service: recurring timeout patterns, missing result collection steps, and job ID loss across turns. By surfacing these patterns, it makes the architectural gap visible before it produces a production incident. The fix is a wrapper architecture decision, not a model improvement, and the pattern layer tells you which integrations need it.
Frequently asked questions
How do we know whether a given internal microservice is async without reading its implementation?
Request the service's API documentation and look for two signals: responses that return a job ID or correlation ID rather than an immediate result, and documentation that mentions webhooks, callbacks, or event notifications for result delivery. Either signal indicates an async system that needs an async wrapper.
Can we make all our async tool integrations look synchronous to the agent by wrapping them?
Yes, and this is the recommended approach for most agent frameworks: abstract the async pattern at the wrapper level so the agent always sees a synchronous interface. The wrapper handles polling, timeouts, and retries. The tradeoff is that long-running jobs block the tool call, consuming the agent's attention for the duration.
What happens when a job starts during one agent session and needs to be checked in a future session?
This requires persistent state outside the agent's context window: a database or cache that stores job IDs with their session associations. Most agent frameworks do not provide this natively. It has to be built in the scaffolding layer and exposed to the agent as a "check job status" tool rather than a state that the agent remembers.