In 1996, Walmart told its top 100 suppliers to adopt Electronic Data Interchange or lose shelf space. Purchase orders, invoices, shipping notices — all structured as ANSI X12 documents, transmitted machine-to-machine, no human typing involved. By 2000, EDI handled over 80% of B2B commerce by transaction volume. The pattern was clear: when both sides of a data exchange agree on a schema, a human in the middle is overhead.
That pattern repeated across every boundary in the enterprise. CRM syncs with billing. Billing syncs with accounting. Payroll syncs with HRIS. Roy Fielding published his REST dissertation at UC Irvine in 2000, and within a decade every SaaS product with a database had an API. Machine-to-machine data exchange became the default. Manual entry became the exception — confined to the edges where structured schemas hadn't reached.
Automation eras · data exchange
The exception that lasted fifty years
Forms survived. Not because the technology was missing, but because the cognitive task they represent resisted automation. A purchase order has a fixed schema: item, quantity, price, ship-to address. A sprint retrospective asks “What would you change?” The answer depends on judgment. On context only the respondent holds. On the political subtext of a Slack thread from last Tuesday.
The form industry understood this. Typeform, Jotform, Google Forms, SurveyMonkey — they all invested in the creator experience. Drag-and-drop builders. Conditional logic. Branded themes. Zapier integrations. Forrester estimated the RPA market hit $2.9 billion by 2021, as companies automated screen-scraping for legacy systems that still lacked APIs. But the form itself — the interface where a human translates their knowledge into structured data — stayed manual.
This wasn't an oversight. It was a structural constraint. Automating a form requires two capabilities: access to the respondent's context (tickets, messages, docs, code), and the ability to exercise judgment about what matters. Machines had neither. RPA bots could click buttons, but they couldn't decide what to write in a text field. APIs could transfer data, but only when both sides agreed on a fixed schema. Forms sit at the boundary between structured output and unstructured reasoning — and nothing could cross that boundary until recently.
The missing consumer
Zapier's “State of Business Automation” reports have tracked this gap for years. Their 2023 survey found that 94% of knowledge workers perform repetitive tasks, and form-filling ranked among the top five. The tools existed to automate workflows around forms — trigger when a submission arrives, route responses to Slack, sync fields to Airtable. But the submission itself was always manual. The respondent stared at a blank textarea and typed from memory.
What changed isn't the form. It's that the respondent now has a collaborator. Claude, ChatGPT, Gemini — assistants that have read the respondent's recent context and can draft answers grounded in what actually happened. The assistant doesn't replace the respondent. It does the retrieval (synthesize two weeks of tickets and threads into a coherent answer) while the respondent does the judgment (read the draft, correct the emphasis, fix the tone).
This division of labor didn't exist in 2020. It barely existed in 2024. By late 2025 it was routine for anyone with an assistant — and McKinsey's 2024 “State of AI” survey found that 65% of organizations were already using generative AI regularly, nearly double the rate from ten months prior.
The form as API
Once the respondent has an assistant capable of filling a form, the architecture question changes. The form is no longer just a UI for humans. It's a data-collection endpoint with two consumers: browsers and agents.
That's the shift. For fifty years, forms had one consumer. Now they have two. And designing for both consumers simultaneously is a different problem than designing for either one alone.
Architecture · one endpoint, two consumers
The HTTP mechanism is old. Content negotiation dates to RFC 2616 in 1997. What's new is that there's a second consumer worth negotiating with. A browser requests HTML and gets a rendered form. An agent requests JSON and gets a structured spec — fields, types, constraints, submit endpoint. Same URL. Same data contract. The consumer decides the format.
No SDK. No browser extension. No plugin. The agent reads a JSON spec, drafts answers from the respondent's context, and submits structured data. The respondent reviews the draft before it goes. The form sender gets a structured response either way — they don't need to know which side typed it.
What this means for form senders
The immediate consequence is practical: response quality improves because the cognitive task changes. Respondents who hand a form to their assistant get drafted answers with dates, names, and specifics instead of “fine.” They review and edit instead of reconstructing from memory. The responses contain signal because the retrieval step — the hard part — is no longer a memory test.
The longer consequence is structural. Forms stop being a special case in the automation stack. Every other data-exchange boundary has an API. Purchase orders have X12. Billing has REST endpoints. CRM has webhooks. Forms have had a textarea and a deadline.
That exception is ending. The last manual API is becoming an actual API — one that humans can also use.