Why your forms need an interface your agents can actually use

Most form tools were designed around a single assumption: a human opens a page, types some answers, and presses submit. Everything downstream — the notification email, the spreadsheet export, the Zapier hop — exists to carry that human's answers to another human.

That assumption is quietly breaking. The thing reading your submissions increasingly isn't a person. It's an agent triaging support intake, a script enriching a lead, a workflow deciding which of three teams owns a request. And the tooling those consumers get is almost always an afterthought: a webhook payload with no schema, a CSV export with renamed columns, an API bolted on years after the product shipped.

The integration tax

When a form platform treats machine access as secondary, every consumer pays the same tax twice.

The first payment is discovery. There is no reliable way to ask the platform what forms exist, what fields this form has, or what a valid response looks like. So every integration begins with someone opening the UI, reading the field labels, and hand-writing a mapping that immediately starts drifting from reality.

The second payment is action. Reading is usually possible; doing anything is not. You can fetch a response, but you can't record that it was reviewed, assign it to an owner, or mark the decision that was made — because the platform never modelled those concepts. So teams invent them somewhere else, in a spreadsheet or a ticketing tool, and the form platform becomes a dead-end inbox that everyone copies data out of.

Parity is the design constraint

The alternative isn't "add an API." Plenty of products have an API that exposes a fraction of what the interface can do, generated from whatever endpoints the frontend happened to need.

The useful constraint is parity: anything a person can do in the interface, a program can do through a documented surface, against the same data and the same rules. Not a mirror of the UI's endpoints — a description of the domain.

Parity has a few practical consequences:

• Schemas are first-class. A form's structure is something you can request, not something you infer from a rendered page.
• Permissions are shared. An agent acting on a workspace is scoped exactly like a member of that workspace, through the same authorization path — not through a global key that sees everything.
• Writes are real. The operational state of a submission — its owner, its status, the decision made on it — lives in the platform and is writable from either side.
• Versioning is explicit. Form structure changes; responses captured under an older structure stay interpretable, because the version they were captured under is part of the record.

What this looks like in Mandda

Mandda exposes its domain three ways over the same core: the application interface, a versioned REST API, and a native MCP server at /mcp.

MCP matters here because it removes the per-client integration step entirely. An agent that speaks MCP can connect, list the tools and resources available to it, and start operating — creating forms, reading responses, updating submission metadata — without anyone writing a bespoke adapter for that particular agent. The capability description is the integration.

Authorization runs through workspace-bound OAuth, so an agent's reach is a property of the workspace it was granted access to. There is no "agent mode" that quietly bypasses tenancy.

And because submissions are modelled as records rather than rows, the write side has somewhere meaningful to write to. An agent can triage a submission and the result of that triage is stored next to the data that prompted it — visible to the humans working the same queue, in the same place, immediately.

The test to run on your own stack

Pick a form your team actually depends on and try to answer three questions without opening the vendor's UI:

1. Can a program discover this form's fields and their types?
2. Can it read the responses, including which structure version each was captured under?
3. Can it record an operational decision about a response, and will a human see that decision in the product?

If the answer to any of them is no, the gap isn't in your automation. It's in the surface you're automating against — and every workflow you build on top of it is carrying a tax you'll keep paying.