arizukoconcepts › web-native agents

web-native agents

each folder is a microsite

Most agent platforms wire a model behind a chat box on someone else's product. An arizuko folder can additionally own 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.

the four pieces

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

piecewhat it doespath
public pageAgent writes into ~/public_html/; vited serves it to anyone./pub/<folder>/*
chat widgetslink embeds in the page; messages land at web:<folder>./chat/<token>/
form intakePOSTs 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 contentAgent 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 gated counterpart, ~/private_html/, serves at /priv/<folder>/ behind OAuth for content not meant to be public.

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
                                          │
                                          ▼
                                        gated
                                          │
                                          ▼
                                   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.

  1. 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.
  2. gated spawns the atlas/strengths/submissions container to process the form post.
  3. 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.
  4. 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

constraints

go deeper