Flow-native website operations

Anpa

The operating layer behind a polished website.

Anpa maps the flows your website triggers, gives operators evidence for running them, and gives developers and agents safe contracts for improving them.

Mapthe flowRunthe workChangethrough gates

Inspect API Open admin

Site System Map

registration-to-follow-up

live model

public siteRegistrationform submitted

sourceAnpa ownedflow instance created

operatorFollow-up readytask + message evidence

agent gatePreview writeapproval required

webhookSite refreshedsigned delivery

Latest evidence

event.registration.created
message.send.preview
approval gate waiting

next action: review follow-up

The problem

A beautiful website can still hide the work that runs the business.

The site collects intent.

A visitor registers, books, buys, or asks for help from a polished public page.

The operation disappears.

Follow-up, access, tasks, payment state, and support context end up scattered across tools.

Agents inherit the mess.

Without a map, code agents add another path instead of strengthening the system already running.

The product object

The Site System Map makes the work visible.

Each flow gets ownership, evidence, operator jobs, allowed operations, and verification commands before anyone edits the site.

Website flow

Name what the public route actually starts: registration, checkout, access, support, or publish.

The site stays custom.

Source of record

Declare whether Anpa, the connected site, or an external system owns each part of the flow.

No guessed ownership.

Operator evidence

Show people, messages, tasks, checkout, access, and webhooks in one flow timeline.

Operators can act.

Safe change path

Give developers and agents allowed operations, preflights, idempotency, and approval gates.

Writes stay bounded.

For operators

Run the business behind the site without editing code.

Anpa turns registrations, access, messages, and follow-up into visible work with owners and evidence.

registrationsfollow-upaccesstasksmessagessupport

For developers and agents

Keep the custom frontend. Move the operations into contracts.

Agents get the same narrow path as developers: read the map, draft a change set, run preflight, then use an approved operation.

OpenAPI/api/anpa/v1/openapi.json

CLI firstnpm run anpa -- map inspect --json

MCP toolsanpa_site_system_map_get

Preflightmaintenance oracle-preflight

01Registration

captured with request id

public operation

02Follow-up

message preview + task

operator queue

03Change

preflight before write

agent gate

First wedge

Registration-to-follow-up for custom websites.

Start with one real flow: a visitor registers, pays, books, requests access, or asks for help. Anpa records the person and flow instance, provisions the right follow-up, and gives the team a safe path for future changes.

Setup modes

Use Anpa where it should own the operation.

Presentation can stay with your site. Anpa owns the durable model, evidence, and safe operation boundaries for the flows you choose.

Hosted

Anpa renders the public flow and owns the operating layer behind it.

Best when the operation should become an Anpa-owned surface.

Connected site

Your frontend stays custom while Anpa powers durable flows behind it.

Best when the site already has the right brand and routes.

Embedded

Drop focused Anpa-backed registration, checkout, access, or catalog surfaces into an existing site.

Best when one bounded flow needs better evidence.

Map the flow before changing the site.

Operators see the work. Developers see the contract. Agents see the path.

Open admin Inspect the API