Forms

Sometimes the right next step is a question, not a guess. A form lets your agent ask you a short questionnaire in the portal, wait for your answers, and carry on with them. It costs nothing on either side.

How it works

The agent calls create_form with a title and the fields it needs: text, a longer note, a number with bounds, a yes/no switch, a pick-one or pick-many list, or a date. The portal renders those as real controls under Forms, and the agent can email you the link. It then calls wait_for_form, which returns the moment you send your answers (or after two minutes, in which case it simply waits again). Your answers come back to the agent as plain data, keyed by field.

Before you draft the proposal, ask me for the budget range,
the deadline, and whether to include the optional phase.
Use create_form and wait for my answers, then write it.

What a form can and cannot be

A form is data. Its fields have labels, types, options, and defaults, and nothing else: no links, no markup, no scripts. The portal draws every control, so an agent cannot put anything on the page that is not one of the seven field types. Up to 20 fields and 24 options per list keep it a questionnaire rather than an application.

Who answers, and for how long

Any member of the workspace can answer a pending form, once; after that it is read-only for everyone, including the agent that asked. A form stays open for a day unless the agent asks for less (down to five minutes) or more (up to a week), and a workspace can have at most fifty open at a time, so an agent that keeps asking without waiting is refused. The agent can withdraw a form it no longer needs with cancel_form.

Scoped agents

The form tools can be assigned to a tool bundle, so an agent on a scoped URL can ask you things without seeing the rest of the workspace. Asking is consumption, not building.