ANAI The Operating Layer for WebMCP

ANAI is an AI agent that discovers and executes real WebMCP tools to automate infrastructure safely, stopping at consequential actions until a human approves.

Comment

The Problem

AI agents are getting very good at reasoning about what users should do. But there is a gap between telling someone how to operate a web application and actually operating that application.

For infrastructure workflows, that gap matters. An agent might be able to recommend a compute service, compare prices, configure an environment, and validate it — but traditionally, the final interaction still depends on clicking through the application's UI or building a separate integration.

We wanted to explore a different model:

What if the web application itself could expose its capabilities directly to an AI agent?

That's where ANAI comes in.

What We Built

ANAI is an operating layer for WebMCP-enabled web applications.

Forge is a simulated cloud infrastructure workspace that exposes its capabilities as WebMCP tools. ANAI discovers those tools through the browser's model context and uses them to operate the application.

A user can simply provide a requirement such as:

"I need an AI backend under $50/month. Don't touch production."

ANAI turns that outcome into an operational plan.

It can then:

  • Discover available infrastructure services
  • Retrieve service details and pricing
  • Compare possible services
  • Calculate the resulting cost
  • Create a development environment
  • Configure the selected services
  • Validate the configuration

For our golden demo, ANAI produces a four-service development environment costing $42.02/month.

But there is an important boundary.

ANAI does not autonomously cross consequential actions. When deployment requires human approval, it stops at a confirmation gate and clearly shows what will happen, the environment, and the estimated cost.

Only after the user clicks Confirm deployment does the simulated deployment proceed.

Production remains unchanged throughout the workflow.

Why WebMCP?

The important part of this project is that ANAI isn't controlling Forge by pretending to understand its UI.

Forge exposes actual capabilities as WebMCP tools.

ANAI discovers those capabilities through the browser and invokes them through the WebMCP API. The results of those calls become evidence for the next steps in the plan.

The flow is:

User requirement → ANAI → WebMCP discovery → real tool execution → Forge state → validation → human approval → result

This creates a much more explicit boundary between an agent and a web application.

The application defines what the agent can do. The agent doesn't invent capabilities that aren't exposed.

Safety by Design

We deliberately designed the demo around constrained autonomy.

ANAI can automatically perform lower-risk, reversible development operations, but consequential deployment actions remain behind a human confirmation boundary.

We also enforce development-only behavior in the demo. ANAI never receives a production target, and production state remains isolated and unchanged.

The confirmation gate is not just visual. The underlying deployment action is blocked until explicit human approval.

We also tested failure scenarios, low-budget requirements, unsupported requests, retries, and repeated deployment calls to verify that the safety boundary and idempotency behavior remain intact.

How We Built It

The project is a Next.js application with a deterministic client-side infrastructure runtime.

The Forge surface exposes 10 WebMCP tools, including service discovery, service details, comparison, pricing, cost estimation, project creation, configuration, validation, deployment, and platform inspection.

ANAI has a deterministic requirement parser and planner. The planner uses the requirement to determine the objective, budget constraint, development environment, and production constraint.

Every agent action goes through the registered WebMCP tool interface:

getTools() → discover capabilities → executeTool(RegisteredTool, JSON.stringify(args))

We also built a second independent WebMCP surface called Repo, which exposes five development-repository capabilities:

  • create_repository
  • get_repository
  • configure_repository
  • set_environment
  • validate_repository

Repo has its own state, types, registration layer, and contract verification, demonstrating that the approach is not tied specifically to Forge.

What We Learned

The biggest lesson was that building an agent that can actually operate a web application is very different from building a chatbot that describes what should happen.

The WebMCP contract becomes an important part of the system design.

We had to think carefully about:

  • What capabilities should the application expose?
  • What arguments should each tool accept?
  • Which actions are safe to automate?
  • Where should human approval be required?
  • How should tool results become evidence for subsequent planning?
  • How do we prevent production state from leaking into an isolated development workflow?
  • How do we make the agent's activity observable without fabricating reasoning?

We also learned that refusing an unsupported request is often better than improvising a plan. ANAI deliberately uses deterministic requirement matching and refuses scenarios it cannot safely support.

Challenges

One of the biggest challenges was preserving a clean separation between agent reasoning, application capabilities, and human authorization.

It would have been easy to create a scripted demo that simply moved through predetermined UI states. Instead, we verified that the workflow uses the actual registered WebMCP tools and that the UI reflects the resulting application state.

We also tested the WebMCP contracts independently, including tool names, descriptions, schemas, argument formats, failure handling, retries, and isolation between Forge and Repo.

The final system has 61 automated tests across 19 suites, along with linting, TypeScript checks, production builds, and Chrome-based end-to-end verification.

The Result

ANAI demonstrates a simple idea:

A web application can expose its capabilities to an AI agent without giving the agent unlimited control.

The application defines the tools.

ANAI discovers and operates them.

The application enforces the boundaries.

And the human remains in control when the action becomes consequential.

That's the direction we wanted to explore with WebMCP.

Built With

Share this project:

Updates

Submission history