Automation and Agents

Agent-Native 0.200.0: A Prompt Recovery Plan for Chat Hosts

Builder.io describes the pieces of setup recovery. This plan defines the host decisions and disposable checks needed to make a recovered request understandable.

By Demetri Panici

October 3, 2026

16 min read

A person compares two document packets under a magnifying glass beside a closed terracotta gate.

On this page

Define the recovery contract before wiring a retry button
Model the states the host must explain
Inventory the inputs before choosing what to resend
Decide what a changed draft means
Reconcile a resend claim with a run outcome
Keep queueing and stopping on separate paths
Test the host contract with disposable requests
Make the ship decision from observable transitions

Imagine a user sending a prompt with a file attached. The server refuses it because AI setup is incomplete. While connecting a provider, the user replaces the file with a revised copy bearing the same name. When setup succeeds, should the chat host resend the refused request, send the current draft, or ask for review?

Builder.io’s Agent-Native toolkit 0.200.0 release notes describe parts of this recovery path: a refused turn saved in the thread, retry context that survives reload, composer draft comparison, and a server claim that limits the after-setup resend to one tab. The Agent-Native Component API documentation shows where a custom host controls composition and submission. That documentation is undated and does not establish that any particular host adopted toolkit 0.200.0.

For a host developer, the decision is how to join those pieces into a recovery path users can understand. Before enabling automatic resend, identify the refused request, establish which inputs would be sent now, and show whether the attempt started a run. The release describes toolkit changes, not a verified integration in your application. Every interface policy and test below is proposed. No host or provider flow was exercised for this article.

Key takeaways

Treat an unsent composer draft and a server-refused turn as different starting states.
Compare the held request with the current draft before automatic resend. Account for references, attachments, and saved run options.
A one-tab resend claim coordinates an attempt. Reconcile it with a resulting run or an explicit uncertain state.
Give setup recovery, queued follow-ups, and stopping an active run separate acceptance criteria.

Define the recovery contract before wiring a retry button

Write the host’s recovery contract as four questions: Which turn was refused? Which inputs would be submitted after setup? Did a new run begin? What happens when the host cannot answer that last question? A button labeled “Retry” needs a defined action for each state.

The release notes say a turn refused before a run starts for missing AI setup or a usable model credential is persisted as a prompt and typed failed run in the thread. They also say the refusal marker and retry context survive a client thread save and reload. Those records give an integrating host something specific to find when the user returns from setup. They do not determine the host’s wording, review policy, or treatment of a draft edited during the interruption.

The Component API documentation describes another path: PromptComposer and TiptapComposer can use submissionDisabled to block sending while still allowing draft, file, and context staging. In that path, the composer may hold an unsent draft. If the user never submitted it, there is no server-refused turn to resend. A host that supports both paths should preserve the distinction in its state and copy.

“Ready to send after connection” could describe an unsent draft. “This request did not start” could describe a saved refusal. These are proposed labels, not documented toolkit strings. Their purpose is to tell users whether the agent received a request. A prompt appearing in the thread does not establish that a run began when the release explicitly describes a prompt stored with a typed failed run.

Connecting a provider changes the setup state. It does not settle whether a user’s edits should replace a refused request. The host makes that decision where its composer meets its submission handler. Document the policy before implementing a retry card so the interface, runtime call, and support instructions describe the same action.

Define the recovery contract. Which turn was refused? Which inputs would be sent now? Did a run begin, or is it uncertain?

Model the states the host must explain

A practical state model separates the interruption from the attempt to recover it. The following labels are a proposed host design, not names of an exported Agent-Native state machine.

Staged draft: What is known: Inputs remain in the composer; no send occurred.; Next decision: Review the current draft when sending becomes available.
Setup-refused turn: What is known: A submitted turn was refused before a run started.; Next decision: Locate its saved prompt, typed failure, and retry context.
Setup underway: What is known: The user is connecting Builder.io or a provider.; Next decision: Keep the pending request identifiable through navigation and reload.
Resend claimed: What is known: A tab has claimed an after-setup attempt.; Next decision: Reconcile the claim with a resulting run or another explicit state.
Run started: What is known: The host can identify a run associated with the request.; Next decision: Show its progress, result, or later failure.
Outcome uncertain: What is known: The host cannot establish whether the attempt started a run.; Next decision: Inspect available records before inviting another send.

The boundary between “refused” and “started” matters. A refused turn has no active run to stop. A started run may already have produced output or used tools. If the host presents both as a generic failed prompt, the next action becomes ambiguous. A user may repeat work that started or abandon a request that never did.

Tie each state to a record the host can inspect. For a refusal, that record is the saved turn and typed failed run described by Builder.io. For a successful resend, the host needs an identifiable resulting run. For uncertainty, the host should say what it checked and what remains unknown. A retry card disappearing is an interface event; by itself, it is not a run record.

Consider an illustrative request to summarize a planning document. A staged draft can wait for setup. A refused turn needs its saved request identified after setup. A run that started and then lost its connection needs its history inspected before another send. The visible prompt text could be identical in all three cases, yet each calls for a different next action.

Use the same distinctions in support and analytics language. “Recovery failed” is difficult to investigate. “The refused turn remained after reload, but the host could not associate the resend with a run” identifies a transition. That is integration analysis, not a measured defect in the toolkit.

Give each state its own record. An unsent draft is not a refusal. A refused turn has a typed failure. A started run needs an outcome record.

Inventory the inputs before choosing what to resend

The saved turn and the current composer draft may diverge while setup is open. Treat them as related records with different jobs. The thread identifies the request that was refused; the composer holds material the user can still edit. The host’s submission boundary decides what to send next.

Builder.io says the retry context includes references, model, engine, effort, and request mode. Its 0.200.0 release notes also describe an optional composer submit() method that sends the current draft with attachments, an onBeforeSubmit callback that receives the held draft, and getDraftSnapshot() for comparison. According to Builder.io, the comparison checks every field of each reference and distinguishes a replacement attachment even when its filename is unchanged. The release does not say that the snapshot alone compares every saved run option; the host should check the options its next submission would use.

The Component API documentation describes PromptComposer attachments, references, draft persistence, and a host-supplied onSubmit handler. Its example passes text, files, references, and options to that handler. This makes the integration boundary concrete: the host receives inputs and decides how to pass them to its runtime. The documentation is undated, so it does not establish when each detail was introduced.

Make an input inventory before building the recovery screen. For each value, record where it comes from, whether the user can change it during setup, and how the host can verify it before submission. Include prompt text, attachment identity and availability, references, exposed run options, and relevant options hidden from the user. Leave an unknown value unknown in the design record. Filling it from a current default without disclosure could turn a supposed replay into a different request.

File identity needs special care. planning-notes.pdf can name two different files. A saved label beside a refused prompt does not establish that the original bytes are available after reload in a particular host. The release supports comparison and submission with attachments; it does not demonstrate successful upload recovery for every integration. Check the material delivered to a resulting run before claiming file recovery works in your application.

References create a similar risk. A prompt may still say “use the project brief” while a reference now points elsewhere. Builder.io’s statement that comparison examines every reference field matters because a text-only comparison could miss this change. The user-facing review can remain simple: show which source the next run will receive and make any change clear.

Inventory files and references. Identify the intended file material. Check changed reference fields. Check the options actually submitted.

Decide what a changed draft means

A comparison is useful when it changes the host’s action. One proposed policy allows automatic resend only when the held request is unchanged and the host can identify its inputs. When an input changed, offer review or submit the edited draft as a clearly new request. The toolkit release describes comparison mechanisms; it does not prescribe this policy for every host.

Relevant inputs still match: Proposed host action: Permit a controlled resend and show its outcome.; What the user needs to know: The pending request appears unchanged.
Prompt text changed: Proposed host action: Ask for review of the current draft.; What the user needs to know: The task wording is different.
A reference field changed: Proposed host action: Show the current reference before sending.; What the user needs to know: The source context may differ.
A file was replaced with one of the same name: Proposed host action: Treat the attachment as changed.; What the user needs to know: The filename does not identify the file.
A run option changed: Proposed host action: Show which setting the next run would use.; What the user needs to know: The run may differ even if the prompt text matches.
An input cannot be identified or recovered: Proposed host action: Pause and explain what needs restoring.; What the user needs to know: The host cannot show what the agent would receive.

Return to the opening example. The original request included a file named planning-notes.pdf. During provider setup, the user selected a revised file with the same name. Builder.io says the draft snapshot can distinguish a replacement. The host could say, “The attachment changed while you connected a provider,” then present the current request for review. It should not describe the next submission as a replay of the original file unless it can establish that identity.

An edit can be intentional. Someone might improve the prompt while waiting for setup. The host can preserve the earlier refusal in the thread and submit the edited draft as a new request. This gives the user an understandable history: one request was refused, then another was sent. A different policy may fit a product, but it should be stated in its interface and checked against its runtime behavior.

Run options belong in this decision too. Suppose the held request used one exposed effort setting and the user changed it while connecting a provider. The sentence and file may be unchanged, yet the resulting run would use a different option. The release says retry context retains options such as effort and request mode. Decide whether an option change triggers review, creates a new request, or is discarded, and show the resulting choice where it affects the user.

Review copy should describe the action the host can establish. “Send current draft” fits when the current draft has changed. “Retry unchanged request” requires a comparison covering the inputs and options the host considers relevant. A generic “Continue” label hides those different actions.

Give edited drafts a deliberate path. Unchanged: consider controlled resend. Changed: review or a new request. Unknown input: pause and restore it.

Reconcile a resend claim with a run outcome

The release notes say the server lets only one tab send the after-setup resend of a refused run. They also describe a retry marker that survives reload, releasing a claim when the thread’s run slot is busy, and sweeping a claim with compare-and-delete. These mechanisms coordinate attempts under the described conditions. A host still needs to tell the user what happened after an attempt.

A claim is narrower than a completed run. It does not prove that work started, finished, or changed another system. The host should associate the attempted resend with a resulting run record, another refusal, or an explicitly unresolved state. If the thread’s run slot is busy, show a state the user can understand after the claim is released. The captured notes do not show how a particular application presents that contention.

Imagine a tab claims the resend and then loses its connection. The send might have started a run before the tab lost its response, or the connection might have failed earlier. Those are hypothetical possibilities, not observed Agent-Native failures. A vanished card could look similar in both cases. Sending again could duplicate work in the first; doing nothing could strand the request in the second.

The useful host behavior is reconciliation. Reopen the thread, look for the saved refusal and any later run associated with the attempt, and show the latest state the host can establish. If that evidence is incomplete, state the uncertainty before offering another send. For an agent that can edit records or create tickets, the host team may also need to check the downstream system. A second drafting run and a duplicate external action have different consequences.

Rise Productive’s guide to deciding what to automate calls for stronger previews, records, limits, and human approval as failure consequences grow. Applied here, a host should require stronger evidence before repeating an action-taking request whose first outcome is unknown. This is an integration recommendation drawn from that decision framework, not a claim that the toolkit provides downstream deduplication.

Keep the product promise precise: the release describes a one-tab claim for the after-setup resend. Exactly-once completion across the host, network, runtime, and external actions would require separate evidence. The supplied capture does not provide it.

Reconcile the claim with an outcome. Find a resulting run record. Make an unresolved attempt explicit. Inspect before inviting another send.

Keep queueing and stopping on separate paths

The same release covers two other conversation moments. Builder.io says follow-up queueing is more reliable, each queued prompt retains its run options, and internal context stays out of user-visible chat text. A queued follow-up waits behind an active run. It does not begin as a prompt refused for missing setup, so its acceptance checks should follow the queued item into its later run.

For example, a user could start a harmless document analysis and queue a short summary with a different exposed option. The host should be able to show which queued request later ran and which option accompanied it. This is a proposed integration check, not a performed benchmark. It tests the queue claim under the host’s conditions; a successful setup retry would not establish queue behavior.

The internal-context claim has a specific surface. Builder.io describes keeping internal context out of user-visible chat text. Inspecting a transcript could show what appeared in that transcript during a disposable attempt. It would not answer every question about where context was stored or transmitted. Keep any host claim within the visible-chat scope unless other evidence supports more.

Stopping begins only after a run starts. Builder.io says useAgentKitStopButton lets hosts rendering AgentKitChat directly stop an active run. The release names the Chat app as an example. It does not establish that every host exposes this hook or specify what happens to every provider operation and external action after a stop. Distinguish three observations: the user activated a control, the reported run state changed, and downstream work ceased or was reconciled. A stopped animation alone supports only an interface observation.

This separation improves support decisions. A setup refusal calls for identifying a saved request and its retry inputs. A queued follow-up calls for checking its retained options and place in the run sequence. A stop request calls for checking active-run state and work already completed. Those questions deserve separate acceptance criteria.

Keep acceptance checks separate. Setup recovery identifies held inputs. Queue checks follow retained options. Stop checks inspect active-run state.

Test the host contract with disposable requests

The following plan is unperformed. Use harmless files and an agent that cannot message people or change production records. For each attempt, record the starting inputs, action order, visible thread state, resulting run count, and any point where the outcome became uncertain. A single passing attempt supports only the conditions exercised.

Staged draft. If the host uses submissionDisabled, stage text, a file, and context while setup is missing. Confirm the interface does not imply a server refusal when no send occurred. After setup, inspect the inputs offered for first submission. The Component API documentation describes draft, file, and context staging while submission is blocked; the host’s rendering remains to be checked.

Refused turn and reload. In a safe state that permits submission but lacks usable AI setup, send a disposable request. Record the refused prompt, typed failure, and connection path the host displays. Reload the thread. Check whether the same pending request remains identifiable. This tests how the host presents persistence described in the release.

Unchanged resend. Leave the held draft unchanged, complete setup, and use the normal recovery action. Compare submitted text, attachments, references, and exposed options with the starting record. Find a resulting run or a clearly reported unresolved state. Count run records rather than answer bubbles: an answer alone may not show which request produced it.

Changed text and reference. Repeat the refusal, then edit the prompt and a reference during setup. Check whether the host applies its stated change policy. If it asks for review, show the relevant difference. If it creates a new submission, make the distinction visible in the thread and record which request the runtime received.

Same-name file replacement. Replace a harmless file during setup with another file bearing the same name. Check that the host treats it as a changed input. If a run starts, verify that it can access the intended material. The release’s comparison capability does not establish attachment-byte survival through every host reload.

Two tabs and a busy run slot. Open one disposable thread in two tabs and follow the host’s ordinary after-setup path. Record what each tab shows and how many runs result. In a separate attempt, make the thread’s run slot busy when recovery is requested. Check whether the host gives the user an understandable next state after the claim handling described in the release.

Interrupted outcome. In a controlled environment, interrupt the tab or network after recovery begins. Reopen the thread and inspect its run record before trying again. Document whether the host can distinguish a started run from a request that never started. This probes an uncertainty boundary; it does not presume a toolkit defect.

Queue and stop. During a harmless active run, queue a follow-up with a distinct exposed option and compare that option with the later run. In another run, use a stop control if the host exposes one. Record the reported run state, continuing visible output, and any tool activity the host can observe. Do not infer provider-side cancellation from the button label.

Write the expected observation before each attempt, then leave the result blank until the attempt occurs. An acceptance record can have three columns: what Builder.io’s release claims, what the host is designed to show, and what the test actually showed. Keeping those columns separate prevents a release statement or proposed interface state from becoming a claimed result. When an observation differs, preserve the request identity, available thread and run identifiers, action order, and visible status so the team can investigate a specific transition.

Observe disposable transitions. Use harmless requests and files. Record inputs, order and run count. Compare expected with observed states.

Make the ship decision from observable transitions

Consider automatic recovery only when the host can identify the refused turn, verify the inputs it will submit, handle a changed draft deliberately, and show the resulting run state. If an input changed, present a review or a clearly new submission. If the host cannot establish whether an attempt started work, expose that uncertainty and support inspection before another send.

The first demonstration can be narrow: take one harmless refused request through setup and reload, compare the request available for resend, and identify the resulting run. Then exercise edits, two tabs, an interrupted outcome, a queued follow-up, and a stop control as separate cases. This test plan is not evidence that any of those cases already pass.

Builder.io describes saved refusal state, draft comparison, one-tab coordination, queue improvements, and a stop hook. Its Component API documentation shows where a custom host owns submission. Neither source establishes your application’s wiring or its behavior after a lost response. Ship the recovery path whose request identity, inputs, and outcome your host can show; keep a review step at any transition it cannot yet explain.