Our Thesis: Rebuilding Data Collection for the Agentic Web

Forms have a structure problem.

Not a styling problem. Not a conversion problem. Not a “make the button larger” problem. Those are real, but they are downstream of something more fundamental.

For most of the web’s history, we treated forms as interfaces for human eyes. A person looks at a page, reads labels, fills boxes, presses submit. The system behind the form can be vague because the human supplies the missing context. If a label is imperfect, the person infers. If a field order is odd, the person adapts. If the backend barely knows what it expects, the frontend can compensate.

That bargain worked because humans were the only serious clients.

That bargain is ending.

The agentic web exposes the old assumption

Agents do not experience forms the way humans do.

A human sees a polite sequence of questions. An agent sees an opaque interface that may or may not reveal the contract underneath. It can scrape labels. It can inspect markup. It can guess field names. It can try a payload and recover from errors. But that is not native interaction. That is archaeology.

The agent is trying to discover a contract that should have been explicit in the first place.

This is what we mean by the Agentic Web: a web where autonomous systems increasingly collect, submit, route, and reason about data on behalf of people. In that world, pixel-first interfaces become insufficient. Not useless — humans still need interfaces — but insufficient as the only source of truth.

Agents need schemas. They need stable endpoints. They need structured errors. They need to know what a system expects before they act.

The old form model gives them a webpage and asks them to guess.

The form was never the box

The word “form” tricks us. It makes us think of fields and buttons. But the important part of a form is not the arrangement of inputs. The important part is the agreement.

• What information is expected?
• Which fields are required?
• What types are allowed?
• What rules are enforced?
• Where does the submission go?
• What happens after it arrives?

That agreement is the form. The UI is just one rendering of it.

Postbox is built around this distinction. A form is a contract made of two pieces: a schema and an endpoint URL. The schema defines intent. The URL is the interface. Anything that speaks HTTP can hold up its side: a browser, a backend, a script, a mobile app, an autonomous agent.

The contract does not care who is holding it.

Discovery should be part of the endpoint

If an endpoint enforces a contract, it should be able to describe it.

This is obvious in APIs and strangely rare in forms. We accept form endpoints that receive data without explaining what they accept. We keep documentation elsewhere, if at all. We let the frontend become the only living description of the expected payload.

Postbox endpoints are self-documenting by design:

sequenceDiagram
    autonumber
    participant A as Admin Agent
    participant P as Postbox
    participant S as Submitter Agent
    
    Note over A, P: Creation Phase
    A->>P: POST /api/forms (Define Schema)
    P-->>A: 201 Created (Opaque URL)
    
    Note over S, P: Discovery & Submission
    S->>P: GET /.../f/contact (Discover Contract)
    P-->>S: Returns JSON Schema
    S->>P: POST /.../f/contact (Submit Data)
    P-->>S: 201 Created
    
    Note over P, A: Orchestration
    P->>P: Run Pipeline (Spam, Translate, AI Reply)
    P-->>A: Webhook/MCP: Submission Ready

• GET with Accept: application/json → returns the schema.
• GET with Accept: text/html → returns readable documentation.
• POST with Content-Type: application/json → submits data.

The endpoint is not just a hole where data disappears. It is the place where the contract lives.

For agents, this is the difference between guessing and knowing. An agent can discover the schema, construct a valid payload, and submit through the same URL a human-facing form would use. No SDK required. No separate docs. No brittle scraping.

Stability matters when clients are autonomous

Autonomous systems do not handle silent contract changes gracefully.

If a traditional form adds a required field, anything submitting the old shape may break instantly. A human might see the new field and adapt. A script cannot. An agent with an old understanding may fail or hallucinate a repair.

Postbox treats schema changes as version changes. A new schema produces a new endpoint URL. Old URLs keep working against the contracts they were born with. New clients can adopt the new URL when ready.

This is not ceremony. It is respect for existing integrations.

The agentic web will be full of long-lived workflows. URLs will be handed from system to system. Agents will act on stored instructions. A contract that changes silently is a trap. A versioned endpoint is a stable object to reason about.

The work begins after submit

Most form tools act as if the job ends when data is received. We think submit is when the real work begins.

Every useful form needs a post-submit pipeline: validation, spam filtering, translation, smart replies, and routing to destinations. Teams rebuild this stack constantly because raw submissions are rarely the thing they actually need. They need clean data, safe data, understandable data, and data that reaches the right system.

Postbox makes that pipeline part of the form backend.

The endpoint is the front door. The schema is the contract. The pipeline is where the submission becomes useful.

Three audiences, one contract

Postbox is designed for three audiences:

1. The owner creates forms, manages schemas, reads submissions, and configures destinations.
2. The submitter posts data to a stable endpoint, whether from a browser, script, app, or backend.
3. The agent discovers schemas, submits valid payloads, and — with permission — uses MCP tools to query and reason about submissions.

These are not separate products. They are different relationships to the same contract. That is the key architectural move. The agent is not a special integration bolted onto a human form. The agent is a first-class client of the form’s contract.

Our bet

Our bet is that data collection is becoming infrastructure for agents as much as for humans.

The old shape — UI first, schema maybe, backend as a black hole — will not hold. The web needs endpoints that explain themselves, schemas that travel with intent, versioning that preserves old contracts, and pipelines that make submissions useful immediately.

Postbox is our attempt to build that layer.

Not another form builder. Not a prettier survey page. The post-submit layer for structured data collection.

A form backend for the web that is arriving.

If you think in contracts rather than pixels, Postbox is built for you.