Aliigo Action Layer

Project name

Aliigo Action Layer (AAL)

Elevator pitch

Aliigo Action Layer makes online business knowledge actionable and future-ready for both people and AI. Using WebMCP, it turns a business’s approved information and capabilities into clear tools that AI assistants can use to find answers, recommend services, prepare bookings or quote requests, and guide customers to the next step—without having to guess their way through the website.

One-line version

Turn your business knowledge into actions that both customers and AI assistants can use.

Tagline

Built for people. Ready for their agents.


Inspiration

Aliigo started from a simple problem: businesses already have valuable knowledge scattered across their websites, service pages, FAQs, policies, booking systems, and other public sources, but that information is often difficult for search engines, AI systems, and even customers to understand consistently.

We have been building Aliigo around the idea that a business should be able to organize and control the knowledge that represents it, make that knowledge easier for Google and AI systems to understand, and put it to work through a Business Agent that can answer visitor questions.

WebMCP suggested the next logical step.

If a business can make its knowledge understandable to AI, why should its customers’ agents still have to guess their way through buttons, forms, menus, and page layouts?

That led to Aliigo Action Layer.

The idea is to give a normal business website a structured action layer for AI agents while keeping the human experience intact. Instead of replacing the website, WebMCP lets us make the same website usable by both people and their agents.

The long-term inspiration is simple:

Make businesses easier to find, understand, choose, and act on.


What it does

Aliigo Action Layer makes online business knowledge actionable.

Instead of asking an AI agent to interpret a website visually and guess how to complete a task, the site exposes structured, business-specific tools that describe exactly what the agent can do.

For example, a wellness business can expose tools that let an agent:

  • understand available services;
  • find an appropriate service for a customer’s need;
  • check available times;
  • prepare a booking.

A printing business can expose a different set of capabilities:

  • find appropriate print products;
  • check artwork requirements;
  • compare relevant options;
  • prepare a quote request.

The important part is that these are not separate one-off integrations.

Aliigo Action Layer uses the same underlying business capability model to expose the appropriate tools for different types of businesses.

The agent can prepare an action while the website shows the result to the human for review and confirmation.

The experience becomes:

$$ \text{Human intent} \rightarrow \text{Agent uses structured tools} \rightarrow \text{Website shows the prepared action} \rightarrow \text{Human confirms} $$

This keeps the human in control while giving the agent a much more reliable way to help.


How we built it

We built Aliigo Action Layer as an isolated WebMCP experiment, separate from the production Aliigo platform but designed with a future integration path in mind.

The application uses a reusable business-definition and capability layer.

Each business defines:

  • its identity;
  • approved business knowledge;
  • products or services;
  • policies;
  • available actions;
  • structured data required for those actions.

A WebMCP adapter then translates those capabilities into business-specific tools exposed through the browser.

We deliberately kept the WebMCP layer separate from the UI and business logic.

Conceptually:

Business knowledge
      +
Business capabilities
      ↓
Aliigo Action Layer
      ↓
WebMCP tools
      ↓
AI agent

The same application can switch between different example businesses and expose a different toolset without rebuilding the underlying architecture.

We also added visible shared state so that when an agent prepares a booking or quote request, the result appears immediately in the human-facing interface.

The current challenge implementation is intentionally self-contained and deterministic. It does not require production Aliigo infrastructure, customer data, external APIs, authentication, or payment systems.


Challenges we ran into

The biggest challenge was thinking differently about what a website interface is for.

Traditional web development assumes that the human is the only actor navigating the interface. Even AI-assisted browsing often follows the same model: the agent tries to understand the page, find the correct control, and interact with it.

WebMCP changes that assumption.

We had to decide which parts of the business should become explicit tools, what information each tool should accept, and which actions should remain under direct human control.

Another challenge was avoiding generic tools.

A tool such as execute_action may be technically flexible, but it gives an agent very little useful business context. We found that tools become much more meaningful when they describe actual business capabilities such as:

  • find_services
  • find_available_times
  • prepare_booking
  • check_artwork_requirements
  • prepare_quote_request

We also had to design around an emerging standard. WebMCP is still experimental, so feature detection, browser compatibility, graceful fallback behavior, and keeping the implementation close to the current specification were important.

Finally, we had to resist turning the challenge project into the full Aliigo platform. The goal was to demonstrate the idea clearly and reliably without reproducing the much larger production architecture.


Accomplishments that we're proud of

We are most proud that Aliigo Action Layer demonstrates something broader than a single WebMCP-enabled form.

The same underlying architecture can represent very different businesses and expose different agent capabilities based on what each business actually does.

A wellness studio can become bookable by an agent.

A printing company can become quote-ready.

Both use the same underlying model.

We are also proud of the human-agent interaction pattern.

The agent does not simply disappear into the background and perform an opaque task. It prepares a structured action, and the website reflects that action back to the human.

That creates a collaborative experience rather than an autonomous black box.

Another accomplishment is keeping business knowledge and actions connected.

The agent is not simply clicking through a website. It is acting through tools tied to structured, approved business information that can support multiple objectives.

That is closely aligned with the larger Aliigo vision: businesses should have greater control over their own information and over the actions that represent them to AI systems and beyond.


What we learned

WebMCP made us realize that making a business “AI-ready” involves more than making its information readable by AI.

There are really two layers:

Understanding

Can the agent reliably understand what the business offers, how it operates, and which information is authoritative?

Action

Can the agent safely do something useful with that understanding?

Aliigo has been focused heavily on the first layer through structured business knowledge, AI visibility, Atlas, and the Business Agent.

WebMCP provides an emerging open-web mechanism for the second layer.

We also learned that agents benefit from much more specific interfaces than humans.

A human can infer what a button labeled Get Started means from the surrounding page.

An agent performs better when the site exposes something explicit like:

prepare_booking(service, date, time)

That shift from visual inference to declared capability is important.

We also learned that the most useful agent-native experiences may not be fully autonomous.

In many cases, the best experience is:

$$ \text{Agent prepares} \rightarrow \text{Human reviews} \rightarrow \text{Human confirms} $$

That keeps agency with the user while removing much of the tedious research and form-filling work.


What's next for Aliigo Action Layer (AAL)

The challenge version of Aliigo Action Layer is intentionally small, but the concept fits naturally into the broader Aliigo direction.

Today, Aliigo is designed to help a business organize its knowledge, improve how search and AI systems understand it, establish a structured public presence, and answer website visitors through a Business Agent.

Aliigo Action Layer adds another output:

Business Knowledge
      ↓
Search + AI visibility
      ↓
Atlas presence
      ↓
Business Agent
      ↓
Agent Action Layer

In a future Aliigo implementation, WebMCP tools would not need to be manually created for every business. They could be derived from the same structured business knowledge and capabilities that Aliigo already manages.

A restaurant could expose reservation tools.

A winery could expose visit-planning and tasting-request tools.

A hotel could expose room and amenity queries.

A manufacturer could expose inventory, capability, and quote-request tools.

A local service business could expose appointment and estimate-preparation tools.

The long-term opportunity is to make agent-ready infrastructure accessible not only to large companies with dedicated engineering teams, but also to ordinary businesses.

The web gave every business the opportunity to have a website, but not every business has one that represents it clearly or makes its knowledge usable beyond the human interface.

We believe the next web will make it easier for businesses to publish structured interfaces for agents as well.

Aliigo Action Layer is an experiment in what that layer could look like.

Built With

Share this project:

Updates

Submission history