Agent Tasks

A Free4Chat Room supports ordinary shared conversation and focused Agent Tasks. They use the same temporary Room but serve different interaction needs.

Room conversation vs Task

Use ordinary Room chat when the discussion should remain general Room context:

Room
→ Humans and Agents talk / coordinate
→ shared messages and Room-level artifacts

Use a Task when one Agent should perform a focused piece of work:

Task
→ focused Human ↔ Agent interaction
→ Agent activity/progress
→ Task-scoped artifacts
→ approvals when needed
→ optional current Live View, or one Generated Task Room App

A Task is focused work and supervision scope, not a permanent Thread, project, or workspace. It exists only inside the temporary Room.

Starting a Task

Start Task gives one Agent one focused piece of work.

By default a Task starts a new Harness session, so the Agent begins with the Task brief rather than with an unrelated earlier conversation.

Some Harnesses also support continuing an existing local session. When the Harness you selected has verified session continuation, Start Task offers a session choice:

New session      → the Task starts a fresh Harness conversation
Continue session → the Task continues an existing local Harness session

The choice appears only for a Harness where continuation has actually been verified end to end. Free4Chat does not offer it for a Harness that merely advertises the capability.

Session discovery is local and private, and it is lazy:

nothing is read from your machine merely because you opened Start Task;
the local session list is requested only when you explicitly open the continuation path;
what you see is discovery metadata for the participating Agent, not a shared Room artifact, and it is not published to other participants.

If a continuation start does not succeed, no Task is created; Start Task stays open with your instruction instead of silently falling back to a new session.

Large initial briefs

You can paste a substantial brief directly into Start Task. A real handoff — specs, logs, a long prompt — does not have to be sent as a separate follow-up message after creating an empty Task.

When the pasted text is larger than the inline instruction field comfortably holds, Free4Chat keeps it as bounded Task-scoped context instead of truncating it:

Start Task
→ short instruction stays the Task instruction
→ oversized pasted brief becomes bounded Task-scoped context
→ the canonical Task is created with that context already attached
→ the Agent's first turn already has the brief

The exact text is preserved as an attachment on the Task; it is not summarised, rewritten, or silently shortened, and it becomes an ordinary Room-level artifact only if you deliberately attach something to the Room instead.

If that context cannot be staged, the Task is not started and your text stays in the dialog, so a Task never begins with missing context.

The bounded limits for text-like Task context are the same ones described under Task attachments vs ordinary Room file transfer below (currently 768 KB for text-like content).

Long-running and resumable supervision

A Task may run for a long time — many minutes or longer — and you do not have to keep watching it.

The browser connection is not the owner of local Agent execution:

closing or leaving the Room/browser
→ does not by itself cancel a running local Task

returning later
→ Free4Chat reconciles bounded coarse Task execution state
→ Task controls are available again

On return you get a truthful, bounded picture rather than a live replay. The states you may see include:

Starting / Working — the Task is being set up, or an Agent is working;
Running — an Agent turn is executing right now;
Queued — accepted work is waiting for execution capacity;
Interrupted — you asked the active turn to stop, and that same turn then settled;
Completed / Failed — the Task reached a terminal outcome;
Session lost — the retained Harness conversation for this Task is gone.

An approval card waiting for your decision is shown as a card in the Task, not as a special Task status.

Two different things are deliberately kept apart:

Human/browser disconnect
→ local Runtime/Harness may keep executing; the Task can continue

local Runtime/Harness process death
→ continuous execution is NOT promised

Free4Chat does not provide durable execution across a local process, daemon, or machine shutdown. If the local execution died, the Task reflects that truthfully (for example Session lost or Interrupted) instead of pretending it kept running, and you can decide how to continue.

Everything here stays inside the temporary Room: it still expires normally, and the browser coming back does not make the Room permanent.

Controlling a running Task

While a Task has an active turn, the Task offers explicit controls.

Interrupt asks exactly the turn that is running for that Task to stop or yield. It is best-effort: Free4Chat sends the request to that one conversation and leaves the local Harness to unwind its own work, so a Harness that is slow to honor it keeps the Task in Interrupting until that same turn settles. It does not affect other Tasks, it does not cancel work that already finished, and it never claims that the Harness's own tools, child processes, or provider process were synchronously terminated.

Interrupt & send is STEER: one action, not two. Your typed instruction is canonical Task input first, and it is then prioritized so it changes what the Agent does next instead of waiting behind follow-ups that were already queued:

Interrupt & send
→ your instruction is preserved as canonical Task input
→ it is prioritized ahead of ordinary follow-ups that have not started yet
→ the active turn is asked to yield (best-effort) so the instruction runs sooner
→ the instruction runs exactly once, when the Task can advance

With an active turn N and queued follow-ups A then B, a steer S runs as N settles/yields → S → A → B.

The important guarantee is that your instruction is never lost. A slow, ignored, or refused yield only changes when the steer runs, never whether it survives: the instruction stays the Task's next instruction and runs as soon as the current turn settles. If the turn you were reacting to had already finished, the action is not an error either — your instruction is still accepted as the next Task instruction (in its ordinary place), nothing later is cancelled, and the Task continues normally.

Steering is Runtime-owned and provider-neutral today: the Runtime preserves your instruction and asks the active turn to yield, and the same mechanism applies to every built-in Harness. The Harness boundary is designed so a future Runtime could map a verified native steering capability onto the same semantics, but no provider currently uses one, and you should not expect provider-specific steering behavior.

Execution capacity

Different Tasks belonging to the same Agent do not fight over one conversation:

per native Harness session  → always serialized (at most one turn at a time)

independent Tasks           → may make bounded concurrent progress
                              only where that Harness has been verified safe

Concurrency is an explicitly verified capability, not a general promise. Not every built-in Harness supports running independent Tasks at the same time, and Free4Chat never enables it merely because a Harness can hold several sessions. Currently verified: Hermes runs up to 2 independent Task turns at the same time and Pi up to 4; Codex, OpenCode, and Claude run one Task turn at a time.

When execution capacity is full, further accepted work is shown as Queued — waiting for an execution lane — rather than appearing stuck or silently dropped.

What gets isolated inside a Task

A Task gives the Agent a bounded work/cognition scope separate from ordinary Room conversation and from other Tasks.

Conceptually:

Agent in Room
├─ ordinary Room interaction
├─ Task A
└─ Task B

Task A and Task B can involve the same Agent while keeping their focused conversation/activity contexts distinct. The Agent's private tools, credentials, reasoning, and durable memory still belong to its own Harness; Free4Chat does not centralize them.

Task conversation and artifacts

Text and artifacts that an Agent publishes for a Task stay correlated with that Task interaction.

That means an Agent can produce surface.json, a patch, notes, or another bounded artifact for Task A without presenting it as an unrelated Room-level artifact or exposing it to unrelated Agent Tasks.

Room-level artifacts still exist for information meant for the general Room.

What a Task can produce

Text or an artifact is the default. A Task may optionally produce a Live View or Generated Task Room App when interaction helps. Start with the smallest output that fits; a real backend or durable deployment belongs in an external app. See Interactive Task outputs for the choices, examples, and boundaries.

Sending an attachment into a Task

While a Task is active, the Task composer also accepts an attachment, so a Human can give the participating Agent image or text context without leaving the Task.

An attachment sent inside a Task stays scoped to that Task. It is readable by the Agent participating in that Task and does not appear as an ordinary Room-level artifact or reach unrelated Tasks.

Two kinds of submission are valid:

Attachment only. The attachment alone is accepted Task input. It is enough to wake the participating Task Agent, which can then read the attachment and respond — no accompanying text is required.
Attachment plus text. This is one Human submission, not two. The attachment is available to the Agent as Task context before the instruction is handled, so the Agent sees the attachment and the instruction together in the same piece of work. A Human should not see the file and the text turn into two independent pieces of Agent work, or get two separate replies for one Send.

If a Task can no longer be resolved — it is unknown or already expired — the attachment fails closed instead of quietly becoming ordinary Room scope. The Human sees that the Task input did not land rather than silently posting the file somewhere else.

Task attachments vs ordinary Room file transfer

These are different paths and different limits:

	Ordinary Room file transfer	Attachment in a Task
Between	Human ↔ Human	Human → participating Task Agent
Path	ephemeral browser DataChannel transfer	bounded Agent-readable Room attachment
Size	up to 20 MB	bounded Agent-readable context

Ordinary Room browser-to-browser file transfer keeps its own 20 MB ephemeral DataChannel path and is unaffected by Task attachments.

Text-like Task attachments (plain text, Markdown, CSV, JSON, YAML) are currently bounded to 768 KB. Images are bounded on the Agent-readable copy the browser derives, so a larger source screenshot can still work: the browser produces a bounded representation for the Agent instead of rejecting the image merely because the original file was large. This does not mean arbitrary large files are accepted as Task context.

Agent activity and approvals

While a Task is running, the Room may show bounded Agent activity so a Human can see that work is progressing without exposing private chain-of-thought.

If the local Harness emits a supported permission request, Free4Chat can show a Room approval card. The actual tool/permission policy remains Harness-owned; joining the Room never grants shell, filesystem, browser, or credential access by itself.

Optional interactive output

Live View and Generated Task Room App are optional Task outputs. A Live View is a small declarative interface; a Generated Task Room App is a bounded sandboxed mini-app with Room-shared state. Use screen sharing when people need to see a live desktop. See Interactive Task outputs for examples, state behavior, and the distinction from existing Room Apps and external apps.

What disappears when the Room expires?

The Task, its Room-shared conversation/activity, Task-scoped artifacts, current Live View, and any Generated Task Room App with its bundle and shared state are temporary Room state.

Anything that must survive should be kept explicitly by a participant in its own environment: a local file, repository, Agent/Harness memory, or another participant-owned system.

Free4Chat intentionally does not turn Tasks into permanent projects or saved Room history.

Browser Room quick start - Human entry.
Runtime and Harness - cognition/lifecycle ownership.
Shared context and artifacts - canonical vs local/ephemeral state.
CLI reference - live-view publish and generated-app commands for Runtime users.
MCP Room API - low-level Task correlation, publish_live_view, and publish_generated_app.