The classic AI API looked like a function: send a prompt, hold the connection, receive a completion. The newest agent and media platforms increasingly look like job systems. A client submits work, receives an identifier, watches state change, handles tool or approval events, and retrieves artifacts later.
This is not merely a fashionable API style. Research agents may browse, write code, and manipulate files for minutes or hours. Video generation and multi-stage media workflows consume variable compute. Remote tools can wait on another provider. A browser tab, mobile connection, load balancer, or serverless request is a poor place to hold the only copy of that work.
Google’s Gemini API and Runway Dev illustrate different sides of the convergence: hosted agent execution and unified media creation. The same architectural lessons apply even though their endpoints and product status differ.
The limits of synchronous request-response
A synchronous call couples four lifetimes: the client connection, the application request, the model run, and every tool it invokes. If any layer disconnects, the application may not know whether the operation failed, continued, or completed. Retrying blindly can duplicate side effects.
Long tasks also produce intermediate information. An agent can have a plan, files, tool traces, approval requests, and partial results before the final answer exists. A media pipeline can upload assets, queue a render, pass moderation, process frames, and package an output. Reducing that lifecycle to “waiting for HTTP 200” hides information operators need.
An asynchronous API decouples those lifetimes. The initial request validates and accepts work, then returns an interaction or job ID. The service progresses independently. The client can poll, reconnect to a stream, receive an event, cancel when supported, and fetch results. The ID becomes the durable point of reconciliation.
Gemini separates interactions from managed execution
Google’s Interactions API reached general availability in June 2026. Its background option allows work to continue after the initial call returns. A client can retrieve the interaction by ID, and server-side conversation state can be continued through a previous-interaction reference. Developers can disable storage for workflows that need a stateless pattern, subject to feature constraints.
Managed Agents is a distinct public-preview layer. Announced in May, it offers Google’s Antigravity agent, powered by Gemini 3.5 Flash, inside an isolated Linux environment. The agent can plan, browse, run code, use files, and call tools. Follow-up interactions can resume the environment with its state and files.
The status distinction matters: the Interactions API itself is generally available, while Managed Agents remains preview. Google documents environment deletion after seven days of inactivity and says outbound network access is unrestricted by default unless the developer applies an allowlist. A hosted sandbox reduces infrastructure work but does not remove network, credential, retention, or output-review obligations.
Remote MCP and custom functions extend the agent beyond its sandbox. The Interactions API supports remote MCP servers using its documented transport and configuration. Registering a tool is an authorization decision, not a discovery convenience. Restrict allowed tools, protect headers, and record which server and schema produced each result.
Runway Dev makes media orchestration a platform concern
Runway announced Runway Dev on July 8, 2026 as an available unified media platform and API. It brings Runway’s first-party models and selected third-party models into one surface, with unified billing and a model switch that Runway says can require only one line of code.
The product goes beyond direct model calls. Recipes package common outcomes as prebuilt endpoints. Workflows let developers assemble a custom pipeline and expose it as a private endpoint. Characters target real-time avatar experiences. Runway also says new models can be available on day one through the platform.
This abstraction increases the importance of job-level observability. A workflow may run several models, and switching one model does not make the complete result instantaneous. Applications need to associate the requested recipe or workflow version, source assets, model choices, cost, moderation outcome, and final artifact with one durable business operation.
The announcement includes enterprise statements around no-training treatment, Zero Data Retention support, SOC 2 Type II, IP indemnification, moderation, and 99.9% uptime. Those are provider claims with plan and contract implications; teams should verify the exact service terms that apply rather than infer them from the launch page.
Remote tools and async jobs solve different problems
Remote tools answer, “Where does this capability live and how can an agent call it?” Asynchronous jobs answer, “How does the operation survive beyond one connection?” They often appear together because remote media and business operations are variable in duration, but neither requires the other.
A remote MCP tool might return a small database record immediately. A conventional REST endpoint might start a two-hour render. A strong agent host must recognize both contracts. If a tool returns a task ID, the model should not repeatedly call the submit operation while waiting. The application should transfer control to a deterministic monitor.
Tool schemas should describe accepted inputs and immediate output, but operational documentation must also define status values, error categories, cancellation, retention, rate limits, and result expiry. Without that second contract, a syntactically correct tool call can still create an unreliable product.
The seven-part async pattern
Across agent and media systems, a durable implementation usually includes these stages:
- Prepare inputs. Validate type, size, consent, and policy before upload or execution.
- Transfer large assets. Use temporary signed locations or managed file APIs instead of embedding video or audio in a model prompt.
- Submit once. Attach an idempotency key or application operation ID when the service supports it.
- Persist the returned ID. Store it before the worker can crash or the user closes the page.
- Observe state. Poll with backoff, consume events, or reconnect to a stream according to the API contract.
- Retrieve and validate. Download the artifact, verify content type, size, duration, checksum, and domain-specific quality.
- Expire and clean up. Remove temporary assets and credentials according to policy, while preserving an audit record.
The application database—not the chat transcript—should be authoritative. A model can decide what to do next, but deterministic code should enforce allowed transitions and deduplicate submissions.
Failure handling is the product
Async systems make partial failure visible. An upload may succeed while submission fails. A job may complete while the status response is lost. A result URL may expire before download. A tool server may return an ambiguous timeout after accepting the operation.
Design a state machine that distinguishes “not submitted,” “accepted,” “running,” “succeeded,” “failed,” “cancel requested,” and “unknown.” Unknown must not be treated as not submitted. Query by the stored provider ID or idempotency key before retrying a side effect.
Polling needs jitter and backoff. Immediate repeated queries waste rate limits; very slow checks harm user experience. Webhooks or streams reduce polling but introduce signature validation, replay protection, ordering, and delivery retries. Many systems use events for responsiveness and periodic reconciliation for correctness.
Medux as a concrete asynchronous media pattern
The Medux tutorials expose the same architecture in a compact workflow, separately from Gemini or Runway. There is no native connection implied between those providers and Medux. In the examples, Codex controls an independently authorized Medux Remote MCP server, while Medux performs the supported media operation.
The Codex video-editing tutorial first inspects two MP4 files. Medux returns temporary signed upload URLs and file IDs; the URLs expire and should not be hard-coded. After both uploads succeed, Codex submits the ordered file IDs to the merge tool. It retains the returned task ID, queries that same task until completion, downloads the MP4 from the result URL, and verifies the output.
The voice-cloning and TTS tutorial applies the pattern to sensitive audio. Codex reads an approved text file, uploads a reference WAV, creates a voice-cloning task, polls until the cloned asset is ready, runs synthesis, and downloads the resulting WAV. Consent and reference-audio security must be handled before orchestration.
An application should persist Medux file and task IDs beside its own operation ID. If an agent reconnects, it should query the recorded task rather than ask the creation tool to run again. A fresh signed URL may be needed for an expired transfer, but that does not necessarily justify a new processing job. Result URLs should be downloaded promptly to approved storage and then validated.
This pattern is broader than one vendor: large inputs move through controlled upload channels, a short request starts durable work, state is observed by identifier, and outputs are retrieved only when authoritative status permits it. New AI APIs are converging on it because the work has outgrown the lifetime of a prompt request.