arizuko › concepts › web-native agents

web-native agents

each folder is a microsite

A route token lets a no-login caller in; the web surfaces are where they land. Most agent platforms wire a model behind a chat box on someone else's product. An arizuko folder instead owns a public website — static pages, an embedded chat widget, a form intake, and content the agent writes itself — with no extra services. The folder is the microsite, which is just the page-one equation pointed outward.

the four pieces

One folder, four surfaces sharing one container and one history:

piece	what it does	path
public page	Agent writes into `~/public_html/`; `vited` serves it to anyone.	`/pub/<folder>/*`
chat widget	`slink` embeds in the page; messages land at `web:<folder>`.	`/chat/<token>/`
form intake	POSTs land at `web:<folder>/<sub>` — that JID requires a real sub-group (e.g. `setup_group atlas/strengths/submissions`); web JIDs are 1:1 with groups.	`/chat/<token>/` (suffixed JID)
generated content	Agent writes HTML, PNG, or JSON into `~/public_html/` over WebDAV; `vited` serves it next request.	same `/pub/<folder>/` tree

Diary, facts, and per-user notes accumulate in the same folder. A private counterpart, ~/private_html/, serves at /priv/<folder>/ behind OAuth for content not meant to be public.

The /pub/<folder>/ path always works, but a world also gets a friendly hostname for free: with HOSTING_DOMAIN set, <folder>.<HOSTING_DOMAIN> 302-redirects to its /pub/<folder>/ slot — no per-host config, no map file. An agent discovers its own public URL with the get_web_presence tool.

flow

visitor
  GET /pub/<folder>/  ──>  vited  ──>  static HTML + chat widget

  POST /chat/<token>/  ──>  webd  ──>  message at web:<folder>
                                          │
  POST /chat/<form-token>/  ──>  webd  ──>  message at web:<folder>/submissions
                                          │
                                          ▼
                                        routd
                                          │
                                          ▼
                                   container (agent)
                                          │
        davd write  <──  ~/public_html/<name>.html
                                          │
                                          ▼
                          next GET /pub/<folder>/<name>.html
                          serves the file the agent just wrote

The form post lands on a sibling chat thread; routing keeps it separate from the page chat.

worked example: atlas/strengths

A visitor opens /pub/atlas/strengths/ and sees an intake form. They paste their Gallup CliftonStrengths results and click submit.

The form POSTs to /chat/<form-token>/; webd writes a message into web:atlas/strengths/submissions. The atlas/strengths/submissions group must exist — web JIDs map 1:1 to group folders, the route table does not apply.
routd dispatches the turn (runed spawns the atlas/strengths/submissions container) to process the form post.
The agent dispatches its process-strengths skill and writes ~/public_html/strengths/<name>.html via davd — served at /pub/atlas/strengths/submissions/strengths/<name>.html.
The visitor is redirected to that new path. vited serves the personalised report on the next request.

what it replaces

The same workflow on a typical stack is a Webflow page, a Zapier or Make webhook, an OpenAI call from a backend, and a storage bucket for the output. Here it's one folder. No CMS, no glue service, no backend code beyond a skill that writes HTML. The agent itself plays the role of CMS, ETL, and generator.

use cases

Personalised reports — paste data, get a report URL; CliftonStrengths, resume reviews, lab results.
Tools — calculators, generators, and intake forms where the answer needs an LLM to compose it.
Customer-facing demos — a one-page site that shows what the agent does, with a working chat next to it.
Submission queues — intake forms whose entries the agent triages, replies to, or escalates to a topic.
Tutors — persistent context per user across visits, with the page itself acting as the workbook.

constraints

One folder, one site. Sub-sites under one folder share the same agent, ACL, and history; for separate sites use separate folders.
Pages are whatever the agent writes. There is no DB-backed templating layer — a dynamic page needs a skill that writes the HTML.
vited is the origin. No CDN, no edge caching; put one in front if traffic warrants it.

go deeper

routing — how web:<folder> and web:<folder>/submissions reach the right agent.
route tokens — the /chat/<token>/ URL the page and form post to.
tasks — schedule the agent to regenerate or sweep the site.
skills — the markdown instruction set that turns a form post into HTML.
webdav — the file workspace the agent writes through.
how-to: chat link — mint the token the page embeds.