webclerk

A WebMCP-powered trust layer for consequential forms that fills only evidence-backed fields, preserves uncertainty and conflicts, and keeps truthfulness and final submission under human authority.

Comment

Inspiration

AI agents are getting very good at filling forms, navigating websites, and taking actions on behalf of users.

But consequential forms create a harder problem:

What happens when the agent sounds confident about something the evidence never actually proved?

For scholarship applications, insurance claims, benefits, compliance workflows, and similar processes, a plausible answer is not necessarily a supported answer.

That led to the core idea behind webclerk:

Evidence > confidence.

The agent prepares. The human commits.

webclerk explores what happens when a website does not merely expose capabilities to an AI agent, but also defines the boundaries of the agent's authority.

What it does

webclerk is a WebMCP-powered trust layer for consequential forms.

Instead of giving an agent unrestricted access to form fields, the website exposes semantic tools backed by deterministic trust rules.

Every field can remain in one of several meaningful states:

  • Verified — supported by current, accepted evidence
  • Needs confirmation — plausible, but requires the applicant
  • Conflict — the form and evidence disagree
  • Human-only — the agent is not authorized to decide or attest it

The agent can safely prepare the application while uncertainty stays visible.

In the scholarship workflow, the agent can:

  • inspect the current application state
  • read supporting evidence
  • find evidence-backed values
  • explain why a field is unresolved
  • check consistency
  • run preflight checks
  • request approval before making supported edits

The site exposes 9 semantic WebMCP tools: 7 read tools and 2 write tools.

There is deliberately no submission tool.

Truthfulness declarations and final submission stay with the human.

How WebMCP is used

WebMCP is not an add-on to webclerk. It is the interaction model.

The browser page exposes semantic capabilities such as:

  • get_application_state
  • fill_verified_fields_from_evidence
  • inspect_field
  • list_evidence
  • suggest_field_value
  • set_field_value
  • find_missing_information
  • check_consistency
  • run_preflight

These tools operate over the same live browser state the user sees.

That means the agent does not need brittle DOM scraping or coordinate-based automation to understand the application.

More importantly, the website itself controls what the agent is allowed to do.

Writes pass through deterministic authorization rules before the visible form state can change.

Live scholarship proof

The scholarship demo begins at approximately 70% completion.

When prompted:

Fill everything you can verify from my documents. Don't guess anything.

the agent identifies six evidence-backed fields and requests approval before writing.

After approval:

  • completion moves from 70% to 96%
  • verified fields increase from 3 to 9
  • 6 evidence-backed agent edits are made
  • 0 unsupported guesses are made
  • 0 consequential agent actions are performed

Every agent mutation is visibly attributed to WebMCP.

But the more important behavior is what webclerk refuses to do.

For example, the enrollment certificate proves that the applicant is enrolled, but it does not establish whether the mode of study is full-time, part-time, or something else.

webclerk leaves that field unresolved instead of inferring it.

Conflicts stay conflicts

The scholarship form intentionally contains an income conflict:

  • application value: ₹3,50,000
  • supporting evidence: ₹3,20,000

webclerk does not silently choose one.

The field remains blocked and preflight surfaces the conflict for human review.

The system also detects stale evidence and preserves applicant-confirmation fields instead of promoting them into verified facts.

The principle is simple:

Blocked, not guessed.

Human authority

Some actions should not be delegated simply because an agent is technically capable of interacting with the page.

webclerk therefore treats actions such as truthfulness declarations as human-only.

If the agent attempts to perform a protected action, the trust layer rejects it.

Final submission is even more explicit:

there is no submit_application capability exposed through WebMCP.

The absence of that capability is intentional.

Proving the architecture generalizes

I did not want webclerk to be a scholarship-specific automation script.

So I built a second live workflow: a motor insurance claim.

It uses the same trust engine and the same WebMCP tool factory, but with insurance-specific domain rules and evidence.

The agent safely prepares:

  • claimant name
  • policy number
  • vehicle registration
  • incident date

while preserving a deliberate repair-estimate conflict:

  • form: ₹85,000
  • evidence: ₹78,500

Fault admission, incident narrative, and truthfulness remain under human authority.

This demonstrates the underlying idea:

Same engine. Same WebMCP layer. Different consequential workflow.

How I built it

webclerk is a browser-first TypeScript application with a reusable deterministic trust engine.

The implementation separates:

  1. workflow data and evidence
  2. deterministic trust rules
  3. agent authority policy
  4. WebMCP semantic tools
  5. shared browser state
  6. human-facing provenance and preflight UI

The WebMCP tool factory is reusable across both the scholarship and insurance workflows.

The project also includes automated tests for:

  • safe evidence-backed writes
  • stale evidence
  • conflicting evidence
  • human-confirmation fields
  • human-only actions
  • tool metadata
  • WebMCP read/write classification
  • machine-readable authority rules
  • adversarial agent behavior
  • cross-domain generalization

Challenges

The hardest part was not getting an agent to fill a form.

The hard part was defining when it must not fill one.

That required treating uncertainty, stale evidence, conflict, provenance, and human authority as first-class states rather than edge cases.

Another challenge was making those constraints useful without making the agent useless.

The goal was not to block automation.

The goal was to maximize safe preparation while preserving the decisions that genuinely belong to a person.

What I learned

WebMCP becomes especially interesting when websites expose more than actions.

A semantic tool can communicate:

  • what the agent can do
  • what evidence supports an action
  • whether approval is required
  • why an action is blocked
  • and what authority the agent does not possess

That changes the relationship between websites and agents.

Instead of an agent trying to infer what a page permits from its DOM, the website can participate directly in defining the collaboration model.

What's next

The current project demonstrates scholarship and motor-insurance workflows, but the trust model can extend to other consequential processes such as:

  • financial aid
  • government benefits
  • visa applications
  • compliance forms
  • healthcare administration
  • regulated onboarding

The long-term idea is a reusable trust layer where AI agents can do substantial preparatory work while evidence, uncertainty, provenance, and human authority remain explicit.

Autofill is easy. Authority is hard.

webclerk is an experiment in making that authority programmable.

Built With

Share this project:

Updates

Submission history