Watch the video:
Formbox Builder is a low-code environment for designing questionnaires end to end. Serious questionnaires need more than fields on a page. They need structure, behavior, data mapping, extraction, and population. Builder covers that whole span. It also gives you built-in ways to inspect, debug, and test the questionnaire as you build it. The feedback loop is part of the design surface.
What the embedded AI Assistant changed
The embedded AI Assistant changed how form designers interact with that environment.
Before, every change meant driving a rich UI directly: opening the right panel, finding the right control, remembering where a setting lives, recalling pieces of the FHIR SDC model, and then checking whether the result behaved the way you intended. That works, but it creates a lot of mental overhead.
The AI Assistant removes much of that overhead because it can operate the same Builder controls on your behalf. A designer can describe the business requirement in natural language and let the AI Assistant translate that into concrete Builder actions: create items, reorganize sections, configure logic, set extraction or population behavior, and prepare the questionnaire for testing.
That changes the working style. Instead of constantly navigating the UI and holding implementation details in your head, you can stay focused on the actual requirement. The AI Assistant handles more of the mechanical interaction with Builder while you evaluate the result.
The important part is that this still happens in the live Builder page. The AI Assistant is not working on a detached copy somewhere else. Every action shows up in the preview in real time, right next to the same controls you can still adjust manually. You keep the visual context. You keep the fast edit loop. You keep the ability to intervene at any moment.
That is why the embedded AI Assistant is so effective. It turns Builder into a collaborative environment where the human brings intent and judgment, and the AI Assistant handles much of the operational work.
Why Builder has to be composable
But questionnaire work often starts outside Builder.
There may be a ticket with requirements. A policy document. A bug report. A specification. A repository with supporting code. Another system the questionnaire has to align with. Sometimes the questionnaire is only one artifact inside a much larger workflow.
In those cases, keeping the AI Assistant inside the Builder sidebar is too narrow. The agent needs access to the wider context as well. It needs to read the ticket, inspect the repo, compare the implementation guide, look at related code, and then make the questionnaire change with all of that in view.
That is why making Formbox Builder composable into other agentic environments is important. A standalone agent in your IDE, terminal, or another MCP-capable environment can combine questionnaire work with all the other materials that usually shape that work in practice.
This opens a different class of questionnaire building. The agent can gather knowledge from multiple sources, reason across them, and then apply the result directly in Builder.
Keep the live loop
Even in that broader workflow, you still want the same thing that makes the embedded AI Assistant good: the live visual loop.
When an agent iterates on a questionnaire, you want to see the result immediately. You want the Builder preview. You want the surrounding UI. You want to make manual adjustments while the agent works. You want the feedback loop to stay short and visible.
To make that possible, the standalone agent has to know exactly which Builder tab it is working with.
That sounds small, but it is essential. You may have multiple Builder tabs open at the same time. One might be a production questionnaire. Another might be a draft. Another might be a scratch playground. If the agent edits the wrong one, the whole workflow breaks down.
So the standalone flow starts with explicit session targeting. Formbox MCP provides tools for this on purpose. A standalone agent can list the open Builder sessions, and you choose which one it should use. After that selection, tool calls are forwarded to the chosen browser page.
That preserves the shared live context between the human and the agent. The agent is not editing some abstract questionnaire resource in isolation. It is working against the exact Builder page you selected.
How the standalone flow works
The architecture is straightforward once you look at it from the right angle.
You configure Formbox as an HTTP MCP server with authentication. The Formbox backend acts as a relay in the middle. The standalone agent talks to the backend over MCP. The backend then routes the tool calls back to the selected Builder page through a WebSocket connection.
The flow looks like this:
- The standalone agent lists the Builder sessions that are currently open in the browser.
- You select the session that should be used.
- The selected Builder tab becomes the active target for the agent.
- Subsequent Builder tool calls are forwarded to that browser page.
- The questionnaire updates in the same live Builder UI you are watching.
That design gives the standalone agent the same practical working surface as the embedded AI Assistant, but inside a much larger ecosystem of tools and workflows.
Same Builder, broader workflow
That is the main idea behind "Builder inside an agent."
Formbox Builder remains the place where questionnaire design happens. It still covers the full lifecycle from structure and behavior to extraction and population. It still gives you ways to inspect, test, and debug the questionnaire as you build it. The embedded AI Assistant still gives form designers a faster and lighter way to work with that power.
What MCP changes is the boundary around that experience.
Now the same Builder session can participate in a broader agent workflow without giving up the thing that makes Builder effective in the first place: a live, shared, visual editing loop. You can collaborate with AI directly inside Builder, or you can bring Builder into a larger agent environment when the job requires tickets, code, documents, policies, and external systems to be part of the same working conversation.
That is not a replacement for the embedded AI Assistant. It is an extension of the same idea.
The embedded AI Assistant reduces UI and spec overhead for form designers inside Builder. The standalone MCP flow brings that same interaction model into a wider tool ecosystem. In both cases, the goal is the same: keep humans focused on business requirements while the system handles more of the mechanics of building the questionnaire.
If you want the concrete setup steps, session flow, and tool details, the best next stop is the Formbox MCP documentation.
