What an AIMEAT node does today. Node version 4.1.2, checked against the code on 2026-10-18; the MCP row on 2026-10-20; the records of processing and the security classes on 2026-10-23; one app open to the internet on a closed node on 2026-10-25; the Messages list's browser copy on 2026-10-25; goals for your agents on 2026-10-25.
AIMEAT (AI Memory Exchange and Action Transfer) is a place where a person keeps what they know, and where their own AIs, other people's AIs and the apps they build can read it, act on it and share it, under the person's consent. The main road in is the AI chat the person already uses, connected over MCP. The web pages show what happened and hold the controls that need a screen.
This list covers two layers:
- Core is the protocol any node can implement: identity, memory, consent, organisms and workspaces, pacing, federation. Specified in AIMEAT-Core-2026-11.md, normative since node 4.0.0; before it, AIMEAT-RFC-v4.0-Core-full.md with its errata.
- Platform is what the aimeat.io reference implementation builds on it: apps, the agent fleet, extensions, AI, commerce, the web surfaces. This list is its inventory, and the Platform reference says how it is put together; it replaces AIMEAT-RFC-v4.0-Platform-full.md since node 4.0.0.
The API contract is openapi.yaml. Where this list and the contract disagree, the contract wins. Individual apps built on the node (Lifecycle Central, the Design Book's apps, games) are not listed here; they are users of these features.
Markers. off means the feature ships but stays off until the operator switches it on. testnet means it defaults to a test network. Unmarked features are implemented; use can still require configuration, credentials, permissions or an installed runtime. This guide does not report which services a particular node has enabled.
Reach names the REST prefix and the MCP tool family, so a developer can find the door. An MCP tool family written aimeat_task_* means every tool starting with that name.
The preferred way to use AIMEAT is to talk to it through your own AI. Everything below exists so that the chat path works first and the screen is the fallback.
| Feature | What you get | Reach |
|---|---|---|
| MCP server | Claude, ChatGPT, Codex, Cursor, VS Code, Grok and other MCP clients can read and act on your node from the chat. The server advertises its available tools when the client connects. | /v1/mcp |
| Purpose-sized MCP surfaces | Eight opt-in tool sets, so an agent sees only the tools its job needs: appdev, agent, service, admin, commerce, primitives (13 tools, everything else through discover and invoke), chat (the node's own chat: about twenty tools at the start, the rest switched on when a job needs them) and full. /v1/mcp stays the complete, frozen set. | /v2/mcp/<surface> |
| Choose permissions when you connect | The approval window for claude.ai, ChatGPT and other services lets you pick read-only, standard, full access, or exactly the permissions you tick, before the connection completes. It names the service by the name it registered with, explains in plain words that the service becomes one of your agents and what an agent is, and says who runs this server with their contact and privacy policy. A line about morsels appears only when the operator paces agents. | OAuth consent screen, GET /v1/wallet (pacing) |
| Hello MCP | One prompt shows the AI is connected, and your profile carries the mark it writes. Anything acting for you can write that mark through POST /v1/memory, so it shows progress; it is not a proof. Setup instructions are per tool, with every field value. | Profile › MCP |
| Handbook | The first thing a connected AI reads: what this node is and which few tools matter for the job in front of it. The whole-node handbook (on /v1/mcp and /v2/mcp/full) ends with what you do on the screen and why, with the links, so your AI hands you the right page before it meets a refusal: signing-in security, payment keys and payout accounts, giving an agent or an app its rights and letting an agent read mail, AI keys and decision rules, and exporting or deleting the account. Everything else is done from the chat. Limits: the handbooks of the smaller tool sets do not carry that list; the skill aimeat-guided-journey does. | aimeat_handbook_get |
| What this node can do, for your AI | This list, in parts your AI can read: the areas first, then one area with every feature, what it gives and where it is reached. Your AI reads it once it knows what you need, to offer the one thing that fits. | aimeat_handbook_get { tier: "features" }, /v1/prompts/features/sections |
| What a setting means, for your AI | The explanations the pages show behind the question mark next to a setting, readable by your AI: a list of the settings by area, then one setting in full, with what it does, its range, what a lower and a higher value give, examples and when to change it, in English, Finnish and Spanish. Ask your AI what a setting does or which value to pick, and it answers in your language with the same words the page uses. | aimeat_handbook_get { tier: "settings" }, /v1/prompts/settings/sections |
| Your path, from your AI to what others use | Your home shows where you are on seven stages, and the first is your profile: your AI interviews you about your work, what you need, what is hard, what you repeat and what is unclear, and turns the answers into a one-page business card that people open and other AIs read (a schema.org profile in the page). Then: a good AI, connected here, a place for your work, apps, agents at work, and shared with others. A stage is ticked when the account really holds it. The interview works on every road: over MCP, or as a prompt to copy into an AI that cannot connect, with the card pasted back; either way your answers stay private in your own record, and every later offer (a shared place, an app, an agent that takes the repetitive work) is read from them. The help page, the settings overview and the chat offer the same next step. Your own AI reads the same path at the end of its handbook and walks you along it one stage per conversation. | Home · GET /v1/home/state (journey) · journey.state · /v1/prompts/welcome-mat · skills aimeat-guided-journey, aimeat-first-conversation |
| Start here, on every main page | The main pages (memory, shared places, agents, connect your AI, wallet, access, packages, apps, notebook, AI) open with what the page is for, the one thing to do first as a prompt to copy into your AI or a button, and what happens next. Fold it away once you know the page. Each page title has a question mark that explains its word in plain language. | Settings & Controls |
| Capability hints | Your AI is told what else the node makes possible and mentions it rarely, when it fits. You switch it off on the MCP page or by telling the AI to stop. | Profile › MCP |
aimeat connect CLI | One command creates a dedicated agent and writes the MCP settings for Goose, Claude Code, Claude Desktop, Cursor or VS Code, without writing your key into a settings file. Also runs as a local stdio MCP server and an ACP bridge. Limits: --surface (a smaller tool set) is used by Claude Desktop only; the other clients get the full tool set, and the command says so. | aimeat connect client <name> |
| Watch the connector in the terminal | A full-screen view of the running connector: how long it has run, its CPU and memory, the traffic to the node and from local clients, each agent's connection, and deliveries as they arrive. Tab shows one agent's open tasks or inbox. It only reads, so it can stay open beside a running crew. | aimeat connect tui |
| Downloadable client config | Pick your client on the page and save the config file the node generates. | connect-install |
| Prompt-driven road | For AIs that cannot connect over MCP (a consumer Gemini app outside the United States, Copilot without Copilot Studio), the pages compose a ready prompt, you run it in your chat and paste the result back. Free and vendor-neutral. A name two apps share (Gemini, Microsoft Copilot) raises one question, which of the two you use, and your answer picks the road. On the home, "My AI can't connect" gives the profile interview as a prompt and turns the pasted answer into your profile card, keeping your answers private. | Contacts, Email, Workflows, Portfolio, front page and home layout pages |
| Attach another MCP server | Attach your Jira, wiki or another service once. Your own AI, agents, apps and this node's chat can use its tools with the permissions you give them. The node stores the credential encrypted and makes the calls, so each client does not need a copy. Hosted servers can use Streamable HTTP or the older SSE transport, with a bearer token, a named API-key header or no sign-in. Attaching and managing need an explicit permission excluded from full access. This node's own address is refused, and a call that would come back to a node it already passed through, for example between two nodes that attached each other, is stopped with 508. | Settings & Controls > Access > MCP servers · POST /v1/mcp-servers · aimeat_mcp_attach · mcp:manage |
| Sign in to an attached MCP server | MCP OAuth lets you approve access at the service itself. Choose sign-in when attaching through Access or REST, then complete the consent screen in your browser. The node stores the tokens and refreshes them when supported. Your AI can start the sign-in and hand you the link; it cannot approve for you. A failed renewal asks you to sign in again. | POST /v1/mcp-servers with auth: oauth · POST /v1/mcp-servers/{id}/authorize · aimeat_mcp_authorize |
| Use what you attached, from chat | Ask your AI which servers you can use, inspect a server's tools and input schemas, then call a tool by name. The node's chat uses the same MCP access through its own agent. An app calls a tool over REST when you give it the mcp:use permission on its consent screen; it never sees the server's address or credential, and it cannot attach or remove a server. Tool discovery can be refreshed when the service changes. A tool's refusal is reported separately from an unreachable server or expired credential. | aimeat_mcp_list · aimeat_mcp_tools · aimeat_mcp_call · GET /v1/mcp-servers/{id}/tools · POST /v1/mcp-servers/{id}/call · mcp:read, mcp:use |
| Manage attached MCP servers | See server status and tools beside Connected accounts on the Access page. Switch a server off without deleting its setup, turn it back on, or remove it and its stored credential. Your AI or REST also changes its display title or description; the page does not. Removing a server does not revoke a token you created at the outside service; revoke that there too when ending access. | Access > MCP servers · PATCH /v1/mcp-servers/{id} · DELETE /v1/mcp-servers/{id} · aimeat_mcp_update · aimeat_mcp_detach |
| Narrow one agent to named tools | Allow a coding agent to read Jira while withholding tools that change tickets. A grant can narrow one agent, one app (written as app:owner/file) or everyone acting for you to named tools, on your own server and on a server the node offers to every owner; there it narrows only your own agents and apps, and another owner's grant never touches yours. Fixed arguments override the caller's values, for example keeping requests in the SUPPORT project. An exact grant takes precedence over the default grant for everyone. Grants narrow existing permissions; they do not create access. | aimeat_mcp_grant_list · aimeat_mcp_grant_set · GET /v1/mcp-servers/grants · PUT /v1/mcp-servers/{id}/grants · tools, locked_input, grantee |
| Read-only access to a server | Let an agent read from a server and never change anything on it, for example an agent that reads security alerts but must not block an address. A read-only grant admits only the tools the server itself marks as read-only. A tool without that mark is refused, and so is a tool the server adds later until the server marks it. Limits: the decision rests on the server's own description of each tool, so a server that marks a changing tool as read-only is trusted. | aimeat_mcp_grant_set with read_only · PUT /v1/mcp-servers/{id}/grants (read_only) |
| MCP call limits and grant expiry | Set a rolling call limit and an end date for an agent or app's grant. Expiry blocks calls until the grant is changed or removed. The call limit counts recorded successful calls and is best-effort: concurrent calls or unavailable usage records can exceed it. Replacing a grant replaces its earlier restrictions. Removing it restores scope-based access, so revoke the agent's use permission when you mean to stop access. | aimeat_mcp_grant_set with call_cap, expires · aimeat_mcp_grant_revoke · DELETE /v1/mcp-servers/{id}/grants/{grantee} |
| A server's own tools in your tool list | Opt a personal server into direct tool listing, called flattening. Permitted tools appear individually with a server prefix, such as jira__search, so your AI can select them directly. The gateway remains available for the rest. This currently covers personal servers; selecting flattening on a node-wide registry entry does not yet add its tools. Direct listing describes top-level arguments; the upstream server validates the full schema. | aimeat_mcp_update with exposure: flatten or gateway · PATCH /v1/mcp-servers/{id} |
| The node's own MCP registry | The operator can attach a server for everyone with an account or for named owners only, and set a price per call. No availability policy, or an empty allowlist, offers it to nobody. A price is in money only: morsels pace how much gets used and are never a price, so a morsel price is refused. Proxied calls cannot take payment yet, so a server with a money price refuses its calls by name until they can; leave it free for now. Only the operator attaches, changes or removes a node-wide server, in person or through their own agent holding operator:admin. | POST /v1/mcp-servers/node · PATCH /v1/mcp-servers/node/{id} · aimeat_mcp_registry_list · aimeat_mcp_registry_set |
| A server that belongs to a team | An organism owner or admin can attach the team's wiki to the group, keeping its credential with the group rather than one member. Membership governs the shared server's visibility and intended use. Attachment and membership-aware REST listing are implemented. Group servers are not yet resolved by the ordinary REST and native MCP tool-list and call routes, so attachment alone does not provide a working shared call path there. | POST /v1/mcp-servers/organism · aimeat_mcp_attach with organism_id · GET /v1/mcp-servers |
| Workspace MCP access | Bind a group's server to one workspace to use that workspace's roles. The access policy allows contributors to call, lets viewers see the server, and excludes group members with no workspace role. Limits: the workspace id is not checked when you attach, so a wrong id lets nobody in; this binding shares the group call-path limitation above. | POST /v1/mcp-servers/organism · aimeat_mcp_attach with organism_id and ws |
| Attached tools are findable | Attached tools appear individually in discovery within your own access, so you can search for a task such as opening a ticket. Entries describe the tool and its server without exposing the outside address or credential. Disabled and unavailable servers are excluded. Discovering an entry does not grant permission to call it. | aimeat_discover with scope: own · discovery source remote-mcp |
| Publish an attached tool as a capability | Give an attached tool a reusable capability description that apps and agents can discover and invoke. Invocation uses the caller's accessible server and credential, with its call restrictions and price. Publishing your Jira capability does not give other people access to your Jira account. Limits: an attached tool is published over REST (you, or an agent holding capability:write); aimeat_capabilities_create makes only manual capabilities, so your AI cannot publish an attached tool from the chat. | POST /v1/capabilities with source type mcp, reference server/tool · aimeat_capabilities_invoke |
| MCP usage and refusals | Proxied calls record the caller, server and tool, duration and outcome in the usage stream. Operators can inspect these records to explain what an agent used and why a call was refused. Refusals recorded by the call service are separate from transport errors; not every rejection before that service produces a usage row. | Usage surface mcp-remote · GET /v1/admin/usage/calls |
| Another AIMEAT node as a server | Name a peer node instead of entering its address. The node resolves the peer's current address on every call and requires an active peering with routing allowed. Ending the peering or removing routing stops calls through this attachment. The peer's own authentication requirements still apply. | POST /v1/mcp-servers · aimeat_mcp_attach with peer |
| A local MCP server on the node off | The operator can attach an MCP server program running on the node's own host over stdio. It requires both the local-process switch and an allowlisted executable command. The executable is matched exactly, and arguments are passed without a shell; the allowlist does not constrain argument values. Only the operator can attach a command through the node registry, in person or through their own agent holding operator:admin. | POST /v1/mcp-servers/node with command, args · AIMEAT_MCP_STDIO_ENABLED · AIMEAT_MCP_STDIO_ALLOWED_COMMANDS |
| Help from the operators | Write to support@operators and everyone who runs the node gets it in one thread. Your AI uses the same address when it gets stuck. | aimeat_dm_send |
| Feature | What you get | Reach |
|---|---|---|
| Account with a global identity (GHII) | Registering gives you name@node-id, the identity everything you own hangs on: balance, profile, trust, agents. | POST /v1/ghii, /v1/ghii/register-web |
| Password, magic link, reset, recovery | Sign in with a password or an emailed link; reset a forgotten password; recover the account. The emailed link opens a browser session and returns the person to the place they asked from: the page of the node, or the app on its own address; it works once, for 15 minutes. The sign-in dialog asks for one with "Email me a sign-in link" on a node that sends mail. A sign-in that comes back refused (a used or expired link, a failed Google, Entra or SAML sign-in, a deactivated account) opens the sign-in dialog with the reason. Limits: the link returns only to a page of this node or to one of its own published apps, and anywhere else goes to the front page; the welcome link an install set sends goes to the front page, or for the owner to the app the set names. | /v1/ghii/login, /v1/ghii/magic-link, /v1/ghii/magic-link/open, /v1/ghii/password/*, /v1/ghii/account/recover |
| Passkeys | Sign in with a fingerprint, face or screen lock and no password at all. Name each device and remove one the day you stop using it. The same passkey signs documents (see Document signing). | /v1/ghii/passkeys/* |
| Two-step sign-in (TOTP) | QR code for an authenticator app, ten backup codes. An operator can remove it if you lose both, and you are told on your account feed who did it. Once it is on, every way in asks for the code: an emailed sign-in link opens a code step before you are signed in. | /v1/ghii/totp/*, /v1/ghii/magic-link/second-factor, aimeat_admin_totp_reset |
| Sign in with Google, Microsoft Entra ID or Casdoor off | One generic OpenID Connect path, switched on per provider. | /v1/ghii/login/:provider |
| Organisation sign-in (SAML) and directory sync (SCIM) off | An organisation connects Entra ID, Okta or any SAML provider. Its directory creates accounts and deactivates them, and a deactivation stops every session, agent credential, key and app permission acting in that person's name. The account's knowledge stays. A setup guide in the admin dashboard shows what the node has actually seen at each step. See organisation-node-sign-in.md. | /v1/ghii/login/saml/:id, /v1/scim/v2/:id, aimeat_admin_sso_* |
| Invitation by an AI | Your AI emails someone a link; they pick a username and get an account. The AI never creates the account itself. Limits: only on a node that sends email; on a node without email the call says no message was sent and gives the AI the portal link to hand on, and the node's discovery document offers the portal instead. | /v1/registration-invites, /v1/invitations/:token |
| Signed-in devices | See your open sessions grouped by device, and your agents' sessions grouped by agent, on the Access page. End one of your sessions, sign out everywhere else, or sign out everywhere. You do this yourself: an agent ends no sign-in unless you give it account:security, and an agent's sessions end on the Agents page. | GET /v1/access/overview (sessions), GET /v1/auth/sessions, DELETE /v1/auth/sessions/{id}, DELETE /v1/auth/sessions/others, DELETE /v1/auth/sessions |
| The Access page | Every way into your account on one page, in words: sign-in methods, apps and tokens acting in your name (take away one right without revoking the whole key), connected outside accounts, sharing groups, and keys unused for thirty days. | Account › Access, aimeat_access_list |
| Owner-only account controls | Password, email, two-step, account deletion and export answer only to you. An agent can handle them only with a permission of its own name, which "full access" deliberately leaves out. | requireOwnerPrincipal |
| Identity verification off | Finnish Trust Network: the bank sign-in through Suomi.fi raises the account's verification level, when the operator has configured it. EU Digital Identity Wallet verification (OpenID4VP, SD-JWT) is not available in this release, because its check does not yet tie a credential to the wallet it was issued to: the node refuses to start with it switched on, and the admin setting refuses to turn it on. | /v1/ghii/verify/eudiw/*, /v1/ghii/verify/ftn/* |
| Verified adult, yes or no | An app or an extension that shows adult content asks one question: is this person a verified adult. The answer is yes or no, the method and when, never a birth date or a name. A bank identification that shows 18 or older answers yes, and so does a payment with a credit card; a debit or prepaid card does not, because a minor can hold one. The answer belongs to the account, so every app reads the same one, and nobody can write it through the memory routes. An extension gets it on every call and can gate on it in its own code. Limits: verifications made before 2026-10-18 kept no birth date, so the person verifies again; the EUDI wallet path is off on every node until its holder binding exists. | GET /v1/ghii/me/adult, AIMEAT.data.adultStatus(), ctx.caller.adult, aimeat_adult_status |
| Verifiable credential | The node issues a W3C identity credential for your own account: as a JWT signed with the node's key, valid for a year, or as plain JSON with no proof. Limits: until the operator sets the issuer's DID, the issuer is a placeholder (did:web:<node>.aimeat.example) that nobody outside can resolve. | GET /v1/ghii/:ghii/credential (?format=jwt), eudiw.vc_issuer_did (AIMEAT_VC_ISSUER_DID) |
| Start page | Choose where you land when you sign in: Home, Chat, or Settings & Controls. | Settings |
| Display preferences | Choose the display language, regional date and number formats, and time zone independently. Unset preferences fall back to the browser. The node refuses a regional format or a time zone it does not know; the display language is stored as given, without a check. | Settings & Controls > Account, PUT /v1/ghii |
Agents are first-class users. Registration creates a person only; an agent arrives when the person approves it.
| Feature | What you get | Reach |
|---|---|---|
| Agent identity (GAII) | Every agent has agent#owner@node-id, its own scoped permissions and trust score, and acts in the owner's name. Owners can organise agents with tags, change their granted access and delete an agent identity. Deleting an agent cancels its open work, and the morsels held for it go back to whoever asked; its finished work stays in the other side's records under the agent's name. The outside accounts the agent connected are removed with it, so a new agent given the same name sees none of them. The trust score is worked out again and stored each time the agent's profile is read over REST; your AI's aimeat_agent_profile shows the stored score, which can be older. | /v1/agents, /v1/agents/:name, aimeat_agents_list, aimeat_agent_profile |
| Agent avatar | Every agent can have its own picture, so you tell your Claude, Codex and Grok apart at a glance. The agent chooses it itself: an emoji, or an SVG of at most 256 kB that may move. It writes the picture to one memory record, agent.avatar, with the ordinary memory write, so no extra tool is needed. Hello Integration asks for it as an optional step, the built-in skill agent-avatar says how, and the Design Book holds nine templates to start from. The picture shows on the Agents page, the agent's own page, home, Fleet, messages, organisms, contacts, the admin list and the agent's A2A card. You can set or remove it for an agent yourself. The picture is public, like the agent's description. An SVG is shown only as an image, so its markup runs nothing. | agent.avatar via POST /v1/memory or aimeat_memory_write; avatar on /v1/agents, /v1/agents/:gaii, aimeat_agents_list, aimeat_agent_profile; GET /v1/agents/:gaii/avatar.svg; PUT/DELETE /v1/agents/:name/avatar |
| Device authorization (RFC 8628) | The agent shows a code; you approve it in the browser and pick its scopes. The standard agent path. When nobody picks any, the agent may read, write and delete your memory (a record it deletes goes to the bin, and you can put it back for seven days; removing anything for good, or deleting an organism, takes a permission you grant separately), read the catalogue, read the workspaces of your organisms, see your other agents, send messages for you (signed as your agent) and save files; the "standard" choice on the approval page also lets it write and publish there. A ChatGPT or claude.ai connection approved on the sign-in page gets the same list. One of your agents that holds the permission to make agents (agent:write) can approve another of yours without you, and gives it only permissions it holds itself. | /v1/agents device flow, scopes.default_agent_scopes (AIMEAT_DEFAULT_AGENT_SCOPES) |
| What an agent was refused | When the node refuses one of your agents a call for a permission it lacks, you see it without reading a log: on the agent's card, with the permission in words and a button that lists every missing permission at once, so you give all of them, some of them, or decline them; on each of its open tasks, as an event in the task's history; and in your AI's list of agents. The card also shows what the agent asked for when you approved it and what of that you did not give. The agent can read its own refusals, so a runtime can tell after a run that it did not do everything it tried; the CrewAI daemon then fails the task with the reason instead of reporting success. A refused agent counts as an agent with a problem on the agents page. A refusal goes away when you give the permission or decline it (a declined permission stays declined on every route, and the agent is still told), ages out after 14 days, and goes with the agent. When the node cannot read the refusals, the agent list says so (refusals_unreadable) instead of showing none, and a refusal still waiting to be written is written when the node shuts down. An agent connected with aimeat connect add --scopes asks for its permissions up front. | Agents > the agent's card, GET /v1/agents (refusals, scope_request), GET /v1/agents/:name/refusals, POST /v1/agents/:name/refusals/decline, aimeat_agents_list, task event scope_denied |
| Allow with one press | When your AI tries something you have not allowed yet, it does not tell you the name of a permission. It gives you one address, and the page there asks one question in your language: what the agent wants to do, with Allow and Don't allow. Press Allow and the AI goes on in the same conversation: a ChatGPT or claude.ai connection renews its access by itself. The tools your AI could use once you allow them stay on its list, so it never says the node cannot do something. You also get the same question in the bell, with an Allow button, and by email (switch it off on the Email page), once per request. Limits: one press gives only what "Full access" carries and the node does not call powerful; anything else (removing for good, AI spending, your mailbox as you, node administration) is the agent's own page, and the AI is given that address instead. Such a refusal reaches your bell and your email too, with no Allow button and a link to the agent's page, where you decide. A permission only the node's operator can use is told only to the operator. An agent connected with a long-lived key, not through the sign-in page, gets an allowed permission on its next sign-in. | /v1/allow?agent=&need=, GET/POST /v1/agents/:name/allow, SCOPE_DENIED with details.allow_url (REST) and the address in the text (MCP), notification agent_permission_ask |
| Agent v2 keys and signed cards | An agent holds its own Ed25519 key and exchanges it for one-hour credentials. Its signed identity card and published verification key let another node verify the agent. Existing agents can migrate in a batch; the Agents page reports failed sign-ins. Device authorization remains supported. | /v1/agents/v2/enrol, /v1/agents/v2/token, /v1/agents/v2/migrate, /v1/agents/:gaii/card, /v1/agents/:gaii/jwks.json |
| Personal access tokens | Revocable tokens with chosen scopes, or a token that acts as you in full, with an optional expiry, exchanged for a short-lived token. Limits: the read_owner_data field is accepted and stored, but nothing reads it, so it gives the token nothing. | /v1/access/tokens, POST /v1/auth/token/exchange |
| Ecosystem apps (GEAI) | A third kind of principal, eco:app#owner@node-id, for outside applications: onboarded through hello, approve and token with key pinning, limited to approved scopes and data areas, revocable like an agent. Managed over REST; no MCP tool covers ecosystem apps. See building-an-aimeat-compatible-ecosystem-app.md. | /v1/ecosystem-apps/* (hello, approve, token, list, revoke), /v1/ecosystem/* (events, subscriptions, read-through) |
| Signed challenge sign-in | An agent signs its identity and a timestamp with its keypair and gets a token; no nonce is fetched or spent. The token lasts the node's token lifetime, 3600 seconds by default. Kept for federation and node signing; device authorization is the mainline. | /v1/auth/challenge, /v1/auth/token |
| Key rotation | Rotate an agent's keypair; its old tokens stop working, and a connector connection opened with one is closed. | /v1/agents/:gaii/rekey |
| Agent portability | Export an agent and import it on another node. Imported trust is capped at 65. Starting a port takes 50 morsels from your balance (the operator sets the amount). After you delete the agent here, its address sends visitors to the new node for 30 days. Limits: the address forwards only to a node this node peers with. | /v1/agents/:gaii/export, /v1/agents/import, /v1/agents/:gaii/port |
| Identity attestations | Two to four parties co-sign a statement with the keys they already hold on this node. Anyone can read it, and the node checks every signature again each time it is read. Limits: the check is this node's answer; the attestation carries no public keys, so a reader who does not trust the node cannot check it alone. | /v1/attestations |
| Document signing | Ask up to ten people or agents on the node to sign a document; only its SHA-256 is kept. A person signs with a passkey, which must check them with a PIN, fingerprint or face, and an agent signs as itself with its key or session, never in its owner's name. The node seals each signature with its own key, so a signature can be checked without the node, and anyone holding the document sees who signed it by its hash, with no account. Signing with your session works only on this node's own pages: an app, and a personal access token you made, sign as you only with a passkey, because a press in a program does not show that you pressed. Each person asked to sign is notified; an agent asked to sign is not. The notification, and your AI's answer when it creates or reads a request, link to the signing app the operator names; on aimeat.io that is the Allekirjoitus app (allekirjoitus.apps.aimeat.io). A passkey signs on the node's own pages or in an app on the node's own domain, and the signature records which of them it came from. Your AI creates the request, follows it and tells you who has signed; it never signs for you. This is an electronic signature in the eIDAS sense, not a qualified one. Its creator can delete a request nobody has signed, with the files the node stored for it; a request that carries a signature is a record and can only be cancelled. Limits: the parties are identities on this node; a request names one document; with no signing app named, the notification names the request without a link. | /v1/docsign/requests, DELETE /v1/docsign/requests/:id, /v1/docsign/requests/:id/passkey-options, /v1/docsign/requests/:id/sign, /v1/docsign/lookup/:sha256, docsign.app_url (AIMEAT_DOCSIGN_APP_URL), docsign.enabled (AIMEAT_DOCSIGN_ENABLED), aimeat_docsign_request_create, aimeat_docsign_requests, aimeat_docsign_request_get, aimeat_docsign_sign, aimeat_docsign_cancel, aimeat_docsign_delete, aimeat_docsign_lookup |
| Signing with an EU Digital Identity Wallet off | Sign a PDF of a signing request in your own EU Digital Identity Wallet. You open a link on the phone that holds the wallet, or scan a QR code with it; the wallet shows the document, you confirm, and the wallet makes the signature through its own trust service, so the node needs no contract with a signature provider. The node checks that the returned PDF is the document that was sent, that the new signature verifies, that its certificate chain reaches a root the node trusts and that the certificate names you, and only then stores the signed PDF in the signer's own files and records the signature in the request. When a second person signs, they sign the already signed PDF, so every signature lands in one file, which every party can download. Your AI can start it for you and follow it. Today it works with the EU reference wallet (Android), whose certificates are test certificates: such a signature is reported as a test with no legal effect. The national wallets (Finland's in 2027) will give a qualified electronic signature. Limits: PDF only, one document per signature; the wallet protocol is the reference wallet's pre-standard one; the operator needs a relying-party access certificate from a registrar. Setup: document-signing.md. | GET /v1/docsign/wallet, POST /v1/docsign/requests/:id/wallet, GET /v1/docsign/requests/:id/wallet/:session, GET /v1/docsign/requests/:id/signed-document, aimeat_docsign_wallet_start, aimeat_docsign_wallet_status, docsign.eudi_enabled, docsign.eudi_rp_credential, docsign.eudi_test_roots (AIMEAT_DOCSIGN_EUDI_*) |
| Signature checks | Check the digital signatures on a document signed elsewhere: a PDF (PAdES and adbe.pkcs7 signatures, document timestamps) or a CMS file (.p7m, or .p7s with its document). Each signature is valid, invalid or could not be confirmed, with the reasons, the signer, the signing time and what proves it, whether the file changed after signing, the certificate chain against the EU trusted lists, revocation (OCSP, CRL), and the eIDAS level (a qualified electronic signature or seal). The answer also lists the AIMEAT signatures this node holds for the same document. Public, with a rate limit, and anyone can check a file in the Allekirjoitus app on aimeat.io without signing in. The operator can turn off the online checks on a node with no internet access (the answer then says trust and revocation were not checked), add root certificates of their own such as a company CA, pin the certificates allowed to sign the EU list, and set the largest file a check reads (25 MB by default, at most 100). Limits: long-term validation data embedded in a PDF is not used; changes after signing are classified by object type; XAdES and ASiC containers are not checked. | POST /v1/docsign/validate, aimeat_docsign_validate, docsign.online_checks, docsign.lotl_url, docsign.lotl_signer_sha256, docsign.trust_anchors, docsign.max_mb (AIMEAT_DOCSIGN_*) |
| Feature | What you get | Reach |
|---|---|---|
| Scopes and roles | Every agent, app and token carries named permissions (memory:read, ai:use, workflow:write and so on). A permission word is enforced on every door, REST and MCP alike. Operator rights are granted on purpose, never inherited. Every signed-in route asks a word of an agent or an app, unless the caller acts on its own record; the 73 routes that asked none before (organism membership, tasks for another agent, schedules, extension actions, cortex reads, installs and more) ask theirs from 4.0.0 and refuse a call without it. The agents and ecosystem apps that existed before were given those words when the node first started as 4.0, so what worked keeps working until you narrow it. | /v1/permissions/*, x-aimeat-scope in openapi.yaml |
| Consent | Grant, list and revoke access to a data pattern for anyone, an agent, an organism, a person, a domain or a node, with an audit log and a receipt. Each consent has a reach: local (read on this node), federation (as local, and matching public records may go to peers) or auth (another node may sign you in). A consent made without a reach is local from 4.0.0 (federation before it); private and dmz are older names for local. | /v1/consent*, aimeat_consent_* |
| A node for its own people only | The operator can set the node to show its content to its own signed-in accounts only. Then nobody who is not signed in sees anything: every address outside sign-in, registration and the machine connections asks for a sign-in, every page (the front page included) shows a sign-in page instead and opens the page the person came for once they sign in, the steps of signing in (an invitation, an app's consent, opening an app or a page, allowing what an agent asked for) still work, apps open only after a sign-in, portfolio and company addresses do not answer, search engines are told to stay out, and a visitor signed in on another node is treated as a stranger. Something made public while the node is closed (a record, a file, a skill, a package, a knowledge package, a data package, a workspace link) is saved for the signed-in accounts instead, and the answer says so in one sentence, so opening the node later exposes nothing new by accident. What was public before keeps its setting, so switching back restores it. With a sign-in limited to your company (registration mode and the Microsoft tenant list) it is a company node. | visibility.content_access (AIMEAT_CONTENT_ACCESS=signed-in), admin Config, content_access in GET /?format=json |
| One app open to the internet on a closed node | On a node for its own people only, you can still open one app to everyone, for example a campaign page with a consent form and a data-request form, while the rest of the node stays closed. You give the reason and how long; the page, its own documents and the intake forms it names in <meta name="aimeat-intake"> open, and nothing else of yours does. The operator decides how: you ask and an operator approves (the default, and the operators can let named people open on their own), you open and the operators are told, or nobody opens. Every opening records who asked, why, when, who approved and until when, and lists every version since; the operators see all of them on one page, hear of every opening and every new version, and close any with one press. A form a new version adds waits for the operator. The app says at its end that it is open to everyone, search engines do not list it without the operator's separate approval, and it closes itself at its end date after a reminder a week before. Your agent opens it only with your approval where the node asks for it. | visibility.app_internet_opening, visibility.app_internet_opening_max_days, /v1/apps/{owner}/{filename}/internet-opening, /v1/admin/internet-openings*, /v1/admin/internet-openers/*, aimeat_app_internet_*, aimeat_admin_internet_* |
| Nothing goes public without you | The operator can make the node ask you before your agents, and also your apps if they choose, make anything public to anyone: a record, a file, an app anyone may open, your welcome page or a company page, an organism, a board, a skill, a workspace page open to the link, a package, a knowledge package or a data package. Without your separate permission (publish:public, which "Full access" does not include) the agent's change is saved as it was, and you get a notification with Approve and Decline. The agent gets the address to give you. An approval makes public only what you were asked about: if it changed in between, nothing is published. You in person are never asked. A new node starts with agents and apps asking; a running node keeps its setting until the operator changes it. | visibility.publish_gate (AIMEAT_PUBLISH_GATE), /v1/publish-requests*, aimeat_publish_requests, a 202 with publish_request from the writing routes |
| Your node's starting levels | When you or your AI save something and do not say who may read it, the node decides, and the operator sets what it decides: an entry, a file, a file an app uploads (such as a game's pictures), a board, an organism, the first share of a workspace, a data package, and whether a new agent is in the public list of agents. A level you name always wins. A running node keeps what it did before until the operator changes a setting; a new node starts private: boards, organisms and data packages private, a shared workspace for accounts here, new agents unlisted. A starting level of public still asks you through the publish gate when your agent lacks the permission. | visibility.memory_default, file_default, app_upload_default, board_default, organism_default, share_access_default, datapackage_default, agent_listed_default (AIMEAT_DEFAULT_*); visibility is optional on POST /v1/boards and aimeat_board_create |
| App grants | A published app gets a short, narrow, revocable token instead of your session. You can narrow it, cap the morsels it may use, or revoke it. A revoke ends its access at once; a narrowing reaches the app when its current token runs out (15 minutes by default). An app may ask for the marketplace words too: exchange:read shows your contracts, your work and who uses what you sell, exchange:write makes and ends contracts within the budget you set, posts needs and bids, delivers work and lists what you sell; spending under a contract still needs contract:spend with its own ceiling, and publishing tells the app which word its calls need. | /v1/app-grants/*, aimeat-scopes |
| Sharing groups and key-space shares | Open a whole corner of your memory, such as everything under news.morning, to a group. What you write there tomorrow is included. The entries stay private to everyone else, and stopping takes effect at once. A "Shared with you" list shows what others opened to you. | /v1/groups*, /v1/shares*, aimeat_group_*, aimeat_share_* |
| The owner sees their agents' data | A file or record your own agent stored is yours to read. The reverse does not hold: an agent reading your private data, or another agent's of yours, still passes the ordinary checks, and gets the records you mark for your agents (owner), for members or for everyone. To let one agent read everything as you do, including private records, you give it memory:read-as-owner, which "Full access" does not carry. Your apps read your records as you. | access guard, owner_scope on GET /v1/memory, GET /v1/memory/{key} and aimeat_memory_read / aimeat_memory_list, memory:read-as-owner |
| Leaving ends access | Removing someone from an organism, blocking them, or their leaving, also removes their agents and their workspace permissions. An invitation cannot grant more than its writer holds. | organism membership |
| Secrets vault | Store an API key that can be written but never read back. The only reader is an extension's outbound request, which fills {{secret:NAME}} in place. | /v1/secrets, aimeat_secret_* |
| What others can read of yours | Ask your AI what a stranger can see of yours and get one list: every record, file, app, shared workspace page, organism, board, knowledge package, package, data package, skill, welcome page, company front page, exchange offering or need and public agent of yours (your agents' included) that someone else can read, each with who: anyone, anyone holding the link, every signed-in account of this node, or the members of one organisation. Each line says how to close it, with the tool and the route. Not counted, and the list says so: a download link made for one file, an app with an access code, a share behind a password, and sharing groups, which name their readers. On a node that shows its content to its own accounts only, nothing is listed wider than signed-in. A kind lists at most 500 items; the counts include everything. The operator gets the same numbers node-wide, with no item in them. Where classification is on, each thing also carries its classification, and what is open wider than its classification allows comes first (section 24). The page is What others can see in Settings. | GET /v1/exposure/mine, aimeat_exposure_report; operator: GET /v1/admin/exposure |
| Permission check | Ask what the rules say about a key or a caller before relying on it. | /v1/permissions/check |
| Account event log | Your account's own history, including who changed what. Joining or leaving an organism and granting or revoking a consent show here, whether you or your agent did it. A password reset or change, a sign-in ended because its token was used twice, and an operator turning your account off or on or giving you the operator role show here too. | /v1/account/events |
Memory is the knowledge a person brought and owns. A value is a record: one key holds one entity or one collection read as a unit.
| Feature | What you get | Reach |
|---|---|---|
| Memory records | A JSON store per identity with visibility (private; owner, for your agents; group; members, for anyone signed in on this node; public), tags, TTL and versions. Up to 1024 kB per value and 1000 keys per identity by default. | /v1/memory, aimeat_memory_* |
| Optimistic locking | A write names the version it read; if someone changed it since, the write is refused rather than lost. Replacing a key over REST always names the version. A write through POST /v1/memory or your AI is checked only when it names one, where 0 means the key must not exist yet, and so is a partial update. | version on PUT /v1/memory/{key}, expected_version on POST /v1/memory and aimeat_memory_write, if_version on PATCH /v1/memory/{key} |
| Memory bulk writes | Write many records in one call. Valid entries are saved; the response counts the created, updated and skipped entries and lists each failed one with its reason. One failed entry does not cancel the others. An entry takes the same visibilities as a single write; any other value fails that entry. | POST /v1/memory/bulk |
| Memory export, import and copy | Export records as JSON, import them with skip or overwrite choices, bundle selected records and files into a ZIP, or, as an agent, copy another identity's public record under your own, one key at a time. Access checks still apply. | /v1/memory/export, /v1/memory/import, /v1/memory/bundle, /v1/memory/copy |
| Delete and restore | A deleted record leaves every list and search at once and comes back whole for seven days. The operator sets the window. Limits: writing the same key again in that time replaces the deleted copy, which then cannot be restored. | DELETE /v1/memory/{key}, POST /v1/memory/{key}/restore, GET /v1/memory/deleted, aimeat_memory_delete, aimeat_memory_restore, quota.memory_delete_grace_days |
| Who wrote this | See every identity that has written or deleted a key, and how many times, newest first. | /v1/memory/:key/hands, aimeat_memory_hands |
| Schema locking | Lock a key to a JSON Schema; every later write must validate, a copy from another identity included. A lock applies to every account, so the node limits who sets which: a pattern that would reach every key is the operator's, an organism's records are locked by its admins or the workspace's creator, and nobody replaces or sits beside another account's lock. Removing a lock removes only that one, and a cortex activation asks the same rule. | /v1/schemas, PUT/DELETE /v1/memory/{key}/schema |
| Search | Full-text search over keys, tags and values, to six levels deep inside a record. Field names are not searched, and each word you give matches words that start with it. The same search on REST and MCP and on both storage backends. | /v1/memory/search, aimeat_memory_search |
| Librarian | One ranked natural-language search across everything you and your agents wrote, including what you put in organisms, with the organism and workspace each hit belongs to. A public scope searches what anyone has made public. Limits: what other members wrote in your organisms is not searched. | GET /v1/librarian/search (scope, prefix) |
| Find a place in the menus | A field at the top of the Settings & Controls menu and of the admin menu. Type a word and the menu narrows to the pages that match, the sections inside a page and, on the admin side, the Config settings, by name or by another word in English, Finnish or Spanish. Enter opens the page at that section; the / key moves into the field. An AI asked where something is reads the same list, with a link to each page and section. | aimeat_handbook_get { tier: "places" }, /v1/prompts/places/sections |
| Files | Upload in one go or in chunks, resume downloads, set visibility per file. Every file stops at the per-file size the operator sets, 10 MB by default, also when it arrives in chunks: the chunked upload (up to 5 GB) carries a large file only after the operator raises that size. A chunked upload holds no more than one file may be, stays open six hours, completes only when every chunk has arrived, and one account keeps at most four open at a time. A file can be shared with a group or with the members of organism workspaces, in one piece or in chunks, from an app (AIMEAT.storage) or an AI (aimeat_storage_upload). A file you download cannot run as a page on the node's address. | /v1/storage, aimeat_storage_* |
| A file says how it was made | A stored file can carry the provenance record of its bytes: say how it was made when you upload it, or attach the record the node made when it generated them (a spoken clip, a picture). The record must describe the same bytes, or the upload is refused. An agent's file that says nothing gets the node's own stamp. A public file is served with its AI marks, and its record answers anyone by id or by the SHA-256 of the file. A file in a folder path can change visibility in place and keep its record. | ai_provenance, ai_provenance_id on POST /v1/storage, presigned and chunked uploads, aimeat_storage_upload; PATCH /v1/storage/{key}/visibility |
| What a file says about itself (content classes) | Every file and long text that arrives is read for its facts, with no AI model: a PDF's title, author, dates, pages, text and signatures (valid, invalid or indeterminate, with the signer); a picture's size, colour depth, camera, when and where it was taken, creator, existing alt text, and whether it declares being made by AI (the node's own provenance record, an IPTC DigitalSourceType in its XMP, a C2PA manifest), with the EU AI Act line saying whether it carries a machine-readable mark; a video's length, size, frame rate, codecs and recording time. Your AI reads the facts before it reads a file again. When you turn them on, and only then, a model also writes a description and alt text (the words in a picture or a scanned page, a video's transcript), sorts the item into content classes (one item can be in several: invoice, contract, report, photo and others, plus your own), and extracts each class's fields as JSON-LD typed by the class's OWL class. Each class says who decided it (the decision model, you, or your rule) and how sure, with a link to the decision. You, or your AI, correct a wrong class or a wrong value: the decision is then marked overridden, and a corrected value stays when the item is extracted again. A model can propose a new class or new fields; you approve them, or let your approval setting or a decision rule do it, and the classes are yours as an OWL ontology in JSON-LD. A scan reads files that arrived before or while it was off, and removes the facts of files that are gone. Every model step is off by default and spends your AI allowance; an item whose sensitivity label keeps it from models gets its technical facts only. Limits: a file over 64 MB is not read; a video needs ffprobe and ffmpeg on the node; the AI mark is read from what the file declares, never guessed; a workspace document gets facts for the member it is stored under. | /v1/content, /v1/content/facts, /v1/content/inspect, /v1/content/correct, /v1/content/scans, /v1/content/settings, /v1/content/classes, /v1/content/proposals, /v1/content/ontology, aimeat_content_*, content_class.mode |
| Presigned uploads | An MCP tool hands back an upload address; the client PUTs the file there instead of pasting it into the conversation. | aimeat_app_publish, aimeat_storage_upload, aimeat_extension_install, aimeat_cortex_install |
| Data map | Read what an app stores, why it stores it, the exact location, who can read it, how long it is kept and what could be lost. Anyone reads the map of a public app; the map of an unlisted, access-coded or operator-hidden app goes only to its owner and the operator, and the map of a community-listed app also to the node's signed-in members. Only the app's owner also gets the findings, such as personal data and missing explanations. A row can also name the classification the app expects for that data by default, such as confidential (see section 24). An app may invite people into organisms, and an invitation can create a new account; its map says so, with what it does (email invitations, invitation codes, new accounts, workspace access, members) and into which organisms, and the app's page shows it under "Who it invites". An app that asks for the permission to invite and says nothing about it gets a finding. The same goes for agents: an agent that holds that permission says on its page, on its card and in the proposal you approve that it may invite people and that an invitation can create an account, and the agent list over REST and MCP carries it as invites_people. It is read from the agent's permissions, so it is always current. Limits: the app finding is a note to the owner and refuses nothing; nothing here changes who may invite. | /v1/datamap/apps/:owner/:filename, aimeat_datamap_get, aimeat_datamap_set, GET /v1/agents (invites_people), aimeat_agents_list |
| Open items | Your own to-do list, kept as one record. | /v1/open-items |
An organism is a shared space for people, their agents and apps. A workspace inside it is where they all read and write the same material at the same time.
| Feature | What you get | Reach |
|---|---|---|
| Organisms | Where work lives between conversations: one place where you, the people you invite and all your AIs, from any vendor, read and write the same material, with members, owners, join requests and an overview. | /v1/organisms, aimeat_organism_* |
| Start from a shape | Create an organism as your own work, a team, a company, a family, a club or a project, and it comes with its workspaces: their spaces, locked schemas and a readme that says what the place is for and what is current, named in your language. The shape sets a safe join policy and visibility, which you can change. If one of the shape's workspaces cannot be made, the organism is still created and the answer names the missing workspace and why (workspaces_not_created). Your AI does the same in one call, and the skill aimeat-organisms tells it when a person needs an organism and how to set one up. The organism page's one-click project template is the same shape. | GET /v1/organisms/shapes · POST /v1/organisms with shape, lang · aimeat_organism_create |
| Invitations | Invite by account or by email; the invitee accepts, declines or ignores. The person accepts in person, signed in, whether the invitation came by account or by email: their agent may decline one for them, but not accept it. An email invitation can say where the invitee lands after joining: an app on this node (for example the app the organism works in) or their profile page. It is written in the language the inviter chooses (English, Finnish or Spanish), else the recipient's own or the inviter's, and names the inviter by display name. | aimeat_organism_invite, aimeat_organism_invite_email (return_url, locale), POST /v1/organisms/:id/invitations/email |
| Which agents an organism admits | A member's agents act with the member's rights. When outside people join, an owner can admit only the agents listed in the Agents section: every other agent is refused on every organism route and tool, and the member list shows only the admitted agents. An agent may narrow this setting; only the owner signed in may open it to every agent again. Only the organism's owner or an admin, signed in, adds an agent to the list, a member's own agent included. | PUT /v1/organisms/:id (agent_access), POST /v1/organisms/:id/agents, aimeat_organism_update (agent_access) |
| Workspaces | Spaces of records (validated against a schema) and documents (markdown), each with drafts, publish, versions, comments, members, transfer and revert. | aimeat_workspace_* |
| A space that only an app's tool writes | An app can close a record space so that an agent writes into it only through the app's own tool. The workspace's structure names the app's extension on that space, and the node then refuses an agent's direct draft, publish, revert, delete, archive, copy or import there. You in person and the app's own page write as before. What the app's tool checks (a quote that must be in the source, a figure that must have been given, one draft at a time) then holds for every agent, and an agent you make from your home is given the tool that calls app tools and told which spaces are written that way. You can let one agent through: an agent you give the permission to write directly (full access includes it) writes such a space as you do. The list that closes a space is changed only by you in person or by an agent with that permission, so an agent cannot open a space for itself. An app adds its tool to a space of a workspace you already had from its own page, and that route only adds. | objectTypes[].extensions in the workspace's structure; tool_only on GET /v1/home/agents/choices/spaces; permission organism:direct; POST /v1/organisms/{id}/workspace/spaces/{space}/extensions?ws=; AIMEAT.organism.nameExtensions |
| Workspace access requests | A member who can see a workspace but not read it asks its creator for access. The creator or an admin sees the requests and the members, then approves (contributor by default, or viewer) or declines. An app's own token can decide; an agent needs the permission to invite. | /v1/organisms/:id/workspace-access (/decision, /grant, /revoke), aimeat_workspace_access, aimeat_workspace_member_grant |
| HTML pages: a presentation without an app | Bring a presentation, a report with charts or a page with pictures and some interaction into a workspace as one HTML page, beside the Markdown pages. Your AI writes, publishes and shares it in three calls and hands out the link; a person whose AI cannot connect pastes the page in the workspace, with a ready-made prompt beside it. The page runs in a frame on its own host: its script runs, but it has no network, no storage that outlives the tab, cannot reach your account or anybody's, cannot move the tab or open windows, and a link it holds opens only after the reader confirms the address. Its pictures are inline or files mapped by name. The node writes the page's text into it, so search and every AI read it. Full screen shows only the page, with the EU AI label at the bottom-left corner as on an app, and so does the page-alone link (the viewer address with &view=page, which aimeat_workspace_share answers as window_url and the frame's strip copies): the page fills the whole browser window. Its own files (pictures, stylesheets, scripts, fonts) load inside the frame. A page an AI made carries its record: on an open link the strip around the frame shows the EU AI label, and the workspace's members also read who made the page; a person pasting a page from another AI ticks that an AI made it (ticked by default). Limits: the page holds at most 1 MB of HTML, keeps its last five versions, and libraries load only from cdnjs, jsDelivr and unpkg. A node shows HTML pages only once its operator sets the page host; until then a page is shown as its text. | aimeat_workspace_write with { title, html, files? } · aimeat_workspace_share · POST /v1/organisms/:id/workspace/documents/:space/:docId/frame · AIMEAT_PAGE_HOST · skill aimeat-html-page |
| Public workspace sharing | Share selected documents and record spaces through a public viewer, from the workspace or from your AI. Choose open access, a password or an account requirement, and withdraw sharing later. A page, a space or the whole workspace can end at a date; a shared HTML page ends after 90 days unless you set another date, and the Share panel extends it in one click. A shared Markdown page's own pictures load for whoever may read the page. The node records the day each page was last opened and marks a page nobody opened or changed for six months, offering to archive it. A page an AI made shows the EU AI label on an open link, in its Markdown for an AI too, and counts as public content in the compliance report; behind a password or for signed-in readers only it owes no label. | /v1/organisms/:id/workspace/share (until), aimeat_workspace_share, /v1/organisms/:id/workspace/public/*, /v1/pub/{owner}/{key}?share= |
| Workspace calendar in your own calendar program | A record space that holds events can be subscribed to from Google, Apple or Outlook calendar as a calendar feed, so approved bookings show there without copying. The workspace's creator or an admin opens the space in the share. A calendar that is not public gets a secret address: the node shows it once, a new one ends the old, and it opens the calendar and nothing else. Only an event's own fields are in the feed. A calendar with no event yet answers an empty calendar, so you can subscribe before the first booking. No page draws the address yet: an app, or your AI through the REST endpoint, sets it. | /v1/organisms/:id/workspace/public/records?format=ics, /v1/organisms/:id/workspace/share (ics_key) |
| Partial document editing | Append to a document or a named section, or replace one section without sending the rest again. Concurrent edits are checked before saving; an ambiguous heading is refused. The result is a draft until published. | aimeat_workspace_doc_append, aimeat_workspace_doc_section_replace |
| Member changes to a workspace | A member with the contributor role adds a space or files sections in a workspace someone else created. The creator or an admin chooses whether such a change lands at once or waits for approval; waiting changes reach them as a notification with Approve and Decline. The change goes into the workspace itself with the member's name on it, and the member is told the outcome. A suggestion that nobody decides in 30 days expires. | /v1/organisms/:id/workspace/spaces, /v1/organisms/:id/workspace/sections/:space, /v1/organisms/:id/workspace/suggestions, aimeat_workspace_space_add, aimeat_workspace_sections_set, aimeat_workspace_suggestions |
| Archive and unarchive knowledge | Retire an organism, workspace, space or record. Archived material is read-only and excluded from normal reads; archive-aware search can find it. Restoring a parent leaves items that were archived separately retired. | /v1/organisms/:id/archive, /v1/organisms/:id/unarchive, aimeat_organism_archive |
| Workspace graphs and reference checks | Inspect relationships across an organism or workspace, find references to missing or archived records, and read the history of structural changes. Reference findings help repair the material; they do not block writes. | /v1/organisms/:id/graph, /v1/organisms/:id/workspace/graph, /v1/organisms/:id/workspace/dangling-refs, /v1/organisms/:id/structure/history |
| Workspace agent engagements | See which agent took which workspace contract, retire the engagement and keep its history, or activate it again. The CrewAI liaison daemon checks retirement before doing that workspace work, for its own owner's agent only: an agent of the same name under another owner is not affected. Access permissions are managed separately. | /v1/organisms/:id/workspace/engagements, /v1/organisms/:id/workspace/engagements/retire, Agents > Contracts |
| Workspace batch writes | Submit several records or documents together. The node checks every item's space, permissions and schema before writing; an invalid item refuses the batch and identifies what to correct. | aimeat_workspace_write with items |
| Approval controls | Request approval for an action, read pending requests and resolve them under the organism's policy. A request about one workspace follows that workspace's own autonomy level when it has one. The workspace's list of actions that always need approval adds to the organism's list and never removes from it. Publishing can require approval; a record can be returned to a draft. A person resolves a request, on the workspace page or over REST, never an agent. Limits: no MCP tool covers approvals, so your AI cannot file a request or list the pending ones from the chat. | /v1/organisms/:id/approvals (arguments.ws), POST /v1/organisms/:id/approvals/:aid |
| Public intake forms | Collect a response without requiring an account. The owner defines the workspace destination, allowed fields and draft or publish mode. The node validates the response against the declared space and schema, with rate limits and spam screening. The owner can cap how many responses one form takes in a day, from all senders together. The sender is told a response arrived only after the node has stored it, and a response that could not be stored uses none of the day's cap. | /v1/intake/forms, /v1/intake/:org/:ws/:formId |
| A conversation with a visitor who is not signed in | A form can take a conversation in place of single responses: a visitor writes, your agent or you answer, and the visitor reads the answers on the same page. Starting one gives the visitor a secret that opens that one conversation and no other; the node stores no copy of it, and the record in your workspace cannot be used to open the conversation. The conversation is three records in your workspace: the visitor's messages, written by the node; the answers, written by your agent or by you in an app; and a signal the node writes when an agent is to answer, which is what wakes an agent that watches it. The node decides what a conversation may cost you, before it stores anything: conversations started per day, messages per conversation, the length of a message, the time between two messages, and how many messages a day wake an agent. When you take a conversation over, or the day's agent messages are spent, a message is still stored, no agent is woken, and the visitor is told that a person answers. The visitor can delete the conversation, and the node deletes it by itself a set number of days after the visitor's last message, on an hourly check, also when you have switched the form off or deleted it. Limits: the visitor's page asks for new answers at intervals, because a visitor has no live channel; the page that shows the conversation and the app where you answer are apps, built on these routes; the only bot screen is the form's hidden field and the rate limits; an agent's answer takes as long as the agent takes to wake and think. | /v1/intake/forms with thread, POST /v1/intake/:org/:ws/:formId/thread, …/thread/read, …/thread/forget; library aimeat-intake.js (AIMEAT.intake.thread) |
| Live documents | A document can embed a mermaid diagram or a live view of a memory key (a table, a list, fields or the value), read again on every open with the reader's own access; a key the reader may not read shows a placeholder. It draws on the node's own pages and in an app that renders with the markdown library (AIMEAT.md.renderRich). | workspace markdown, an aimeat-memory fenced block |
| Rows | Store typed tabular events in a workspace. Read pages with indexed field filters, event-time ranges and an update-time filter for incremental sync. Inspect row counts, size and date ranges without downloading the rows. Limits, each set by the operator: 50 000 rows per workspace, 100 MB of rows per organism and 256 kB per row by default; a space with a retention window (maxRows, maxDays) keeps itself under them. | /v1/organisms/:id/workspace/rows/:space, aimeat_workspace_rows_* |
| Row retention and deletion | Remove one row or rows older than a chosen ingestion date. Retention uses when data arrived, so an old event imported today is not immediately removed. Row deletion is irreversible; row spaces have no version history to restore. | aimeat_workspace_rows_delete |
| Extensions in a workspace | An extension that declares it may read and write a workspace on behalf of whoever called it, under that person's rights, so rules live on the node. Your AI can bring hundreds of records at once through an app's own tool: the extension behind it publishes up to 1000 records in one step, first as a dry run that shows what is new, what is already there and what is invalid, and takes an import back out in one step. Each record is checked against the space's locked structure on its own. An extension can also archive up to 500 records in one step, so a space that only grows, such as closed tickets, stays fast to read: archived records leave every read and can be restored. Limits: when the organism reviews every publish, a batch is refused and the records go in as drafts for a reviewer; removed records (up to 2000 in one step) go to the bin, where each can be restored for the node's grace period, and removing asks an agent or app for the permission to delete (memory:delete); only the organism's creator or an admin may archive. | extension manifest, ctx.workspace.publishRecords, ctx.workspace.deleteRecords, ctx.workspace.archiveRecords, POST /v1/organisms/:id/workspace/records/publish (dry_run, create_only) |
| Rows from an extension on a schedule | An extension can fill a shared row space with nobody present, for example a feed of security alerts fetched every five minutes. An admin of the organism names the extension in the space's definition, and the extension asks for row access in its manifest, which the person installing it sees. Each row records the extension as its writer, and a row sent again with the same id replaces the earlier one, so a repeated fetch does not duplicate. It reads the rows back a page at a time, or one row by its id in a single call. Limits: the extension reaches only the row spaces that name it, its installer must be a member, and on a schedule it can neither read nor write records or documents. | manifest workspace: { rows: true }, space extensions: [installer/name], ctx.workspace.appendRows, ctx.workspace.readRows, ctx.workspace.readRow |
| Organism export and import | Take an organism out as a bundle and bring it back: its settings and every workspace you can read, with records, documents, images and the rows of its row spaces. Any active member can export, and the bundle holds only what that member can read. Limits: one workspace's export reads every memory record up to 200 000, and at most as many rows as a workspace may hold; when it reaches a limit, the answer says so (truncated). An import refuses rows that would not fit the row quotas before it writes anything. | aimeat_organism_export, aimeat_organism_import |
| Knowledge packages | Structured knowledge as a package of entries, with links between packages: import one, share it or set each entry's visibility, clone and export it, contribute it to an organism, and read its reputation and the operator's reviews. The public page shows the AI label of the package and of each entry an AI wrote, and the export carries each entry's record. | /v1/knowledge/*, aimeat_knowledge_* |
| Skills | SKILL.md packs at node and user scope, linked to agents, pinned by version, and bound to an app when they are that app's operating guide. Downloadable as a ZIP for Claude and other runtimes. Every node ships its own operating guides for an AI as built-in skills, so an AI on any node reads them from the node and not from a repository file: for example building an app (aimeat-app-builder), using AI from an app (aimeat-ai-capabilities), an agent that works inside a workspace (aimeat-workspace-contracts) and putting recurring work on a clock (aimeat-recurring-work). See skills-registry.md. | /v1/skills, node:<name> on aimeat_skill_get, aimeat_skill_*, /.well-known/agent-skills/index.json |
| Typed records and shared vocabularies | Describe what a record means with JSON-LD types. Keep a SKOS vocabulary with multilingual names, broader and related concepts, and deprecated terms with replacements. Cortex ontologies also expose a SKOS description. | /v1/ns, aimeat-onto, memory records |
Where a person's agents are onboarded, given work, directed and observed.
| Feature | What you get | Reach |
|---|---|---|
| Choose an agent by what it should do | The Agents page starts with one question: should the agent answer when you ask, work while you are away, do the same thing on a timetable, or work for an app? The answer names the kind, where it runs (your chat AI, your computer through the connector, this AIMEAT, or another service), what it needs from you and who pays, and opens the one place that makes it, with the connector's install commands where one is needed. With no agents yet, three examples fill in the form for you. Each agent's card says where it runs, what it thinks with, who pays and how many tasks it finished this week, its last task with who ordered it (you, another of your agents or an app) and when, and a worker has one switch for whether it starts work by itself. The Fleet page leads with what your agents did this week. Your AI has the same choice and the picture of where agents run in the skill manage-my-agents. Limits: where an agent runs and its model are read from what the node knows of it, and its model is what the agent reported. | Profile › Agents, Profile › Fleet, GET /v1/agents?include=stats (doneWeek) |
| Hello Integration | A step-by-step onboarding that proves an agent works: it identifies its platform, installs its skill, reports capabilities, reads its directives, and completes a real test task. Installing the skill and reading the directives are the agent's own report and cannot be checked from outside; the test task and the automatic checks are the proof. Agents that live only inside a chat window (Claude Desktop, VS Code) get the four steps that apply to them. | aimeat_onboarding_* |
| Agent webhook delivery and diagnostics | Configure or remove the webhook that receives agent work, send a delivery test and inspect delivery history. Requests carry an HMAC signature. The Integration tab also shows onboarding progress, skill-bundle versions and instructions to reconnect or update the agent. | Agents > Integration, /v1/agents/:name/webhook, /v1/agents/:name/webhook/test, /v1/agents/:name/webhook/log |
| Basic agents and runtime attachment | The owner can create the basic agent set and enrol it through a connected runtime. An existing agent can be attached when its runtime becomes available. The response states whether the runtime accepted the agent. An agent approved while no connector was running waits for it: when one of the owner's connectors next connects, the node offers it the keys of those waiting agents, and nobody has to press Attach. A connector that refuses leaves them waiting, and the node log says why. | /v1/agents/v2/basic-agents, /v1/agents/v2/agents/:name/attach, aimeat_agent_basics_get, aimeat_agent_basics_request |
| Agent proposals | An AI proposes an agent with its purpose and instructions. The account owner approves or declines it. Approval creates the agent and its definition, then attempts to attach it to the owner's runtime. The proposal's answer gives the address of the page where the owner approves it. The owner's own agent reaches the proposal tool, and the handbooks tell it to build the agent on the owner's organisms and workspaces instead of pointing to an outside builder. An agent that comes with an app is proposed with the permissions the app declares for it, and only those its proposer may give: never all permissions or one of the permissions only you grant by hand, and the answer names what was left out. Approval gives the agent the permissions its runtime needs to start, and ai:use when your crews think through this node. When your connector starts agents per job, a request to keep the agent running becomes start-per-job, and the answer says so. | /v1/agents/v2/agent-proposals (run_mode_corrected), aimeat_agent_propose |
| Connectors as named computers | Each connector (aimeat connect serve) that holds your agents is listed as a computer: its name, whether it is connected, when it was last seen, the agents on it and the agents that wait for it. The connector reports its computer's name, and you can give it your own. A computer stays on the list after it disconnects, and you can forget one that is not connected. When you propose or approve an agent you can name the computer that runs it. Only that computer is given the agent: when it is switched off the agent waits for it, and your other computers are not given it. You can move an agent to another computer: an agent that waits is sent there, and an agent that is running gets a new key on the new computer while the old computer's key stops working. The old computer removes the agent from its own folder when it is told, and its other agents stay connected. It also writes down which agent left and why (moved or deleted), and a runtime on that computer reads this from the connector to remove the files it kept for the agent, without a call to the node; the note is kept for 30 days and is dropped when the agent is on that computer again. An agent that was always on becomes one that is started per job when its new computer keeps no agent running, and the answer says so. Each agent in the agent list names its computer (install_id). Your AI reads the same list and can name a computer in a proposal. Limits: an agent that is running moves only to a computer that is connected; an old computer that was switched off during the move keeps the agent's files, marks the agent as refused at its next start and does not run it; files a runtime kept on the old computer's disk do not move; the computer id and its reported name are not signed, so they tell your own computers apart and prove nothing; a connector released before 2026-10-10 reports no name; a connector from before September 2026 has no id and cannot be chosen. | GET /v1/agents/v2/connectors, PATCH and DELETE /v1/agents/v2/connectors/:id, connector on POST /v1/agents/v2/agent-proposals, install_id on its /approve, POST /v1/agents/v2/agents/:name/move (run_mode_corrected), install_id on GET /v1/agents, aimeat_connector_list, aimeat_connector_rename; on the connector itself GET /local/departed |
| Ideas to start from | When you do not yet know what to ask an agent or an app for, your home shows ideas. The new-agent page shows three examples under the box and opens all of them in a dialog: agents that were made from one sentence and ran for real, filed by what they help with (meetings and work, customers and mail, money, people, health and home, web and news), each with what you get, when it works and the app it works through. Choosing one puts its sentence in the box, and you change it before anything is made. The dialog's second tab pairs an app with the agent that works through it: what you do, what the agent does with the app's tools, and what the app shows of the agent's work; a ready app says so, and an idea gives you the request to copy to your own AI. The home's "Make an agent" and "Make an app" open the same dialog, and an example you choose there goes into the prompt you give your own AI. An agent's own page offers the app ideas for an app of its work. The list is one record the operator edits on the Prompts page, in each language, and your connected AI reads the same list. | GET /v1/prompts/home-ideas?lang=; MCP aimeat_handbook_get { tier: "home-ideas" }; the managed prompt home-ideas |
| Make an agent from your home | Your home has a block for your agents. You say in one sentence what a new agent should do, and a page shows the agent before anything is made: its name, what it is for, what it does, when it works (when you ask, by the clock, when someone writes to it, always on, or when something new arrives in a workspace), what it reaches, and which computer runs it when you have more than one. The page also asks which model the agent thinks with: it lists the models the chosen computer reaches, the model you pick is stored for the agent before it starts, so its first work already uses it, and with no pick the page says that the computer uses the model in its own settings, which can be a small one. For an agent that works when something new arrives, you choose the workspace and the record spaces in it; the agent then gets one task for each record published there. It is stated on the workspace, where you or the workspace's creator can retire it (and where the organism admits only the agents on its list, it is added to that list); a retired agent is no longer sent that workspace's records. You can also let it work on the records that are already there: the page shows how many there are, and each becomes a task, ten at a time. These choices are offered when the agent program on the chosen computer says it supports them; the computer says so itself when it connects, so it can be chosen before any agent is on it. The AI model that writes the agent is told which tools your own apps publish and which workspaces you have, so an agent for something you keep here is built on it; the page then names which of your apps' tools the agent uses and which of your workspaces it reads or writes, before you start it. You change what you want and start it. A proposal from your own AI waits in the same block and opens on the same page. The block lists the agents at work, each with when it works, its computer and what it is doing, and your computers. An agent's page shows the same facts, takes a task for it, holds the conversation with it (the same one as its Messages tab), lists its latest work and moves it to another computer. Each piece of work in that list opens on a page of its own, which shows what the agent was asked to do, where the work stands, the agent's own words about it and what it produced: text as a document, an image as an image, data as a tree. A new agent does its work once the moment it is made, so you see that it works and have a first result. Its definition carries one offer, written by your AI model or made from the agent's name and purpose, and the page shows it before you start the agent; once the agent has started, the offer is on your "Ask your agents" page with no price, and it is not on the Exchange until you put it there. You choose where an agent's finished work goes: its own memory, which only you read, or one workspace of an organism you are in, whose members then read each result the agent finishes from then on; nothing is copied or moved, and the page of one piece of work says where its result is and who sees it. Right after an agent is made, and later from the Apps section of its page, you can make an app of its work: you say in one sentence what you want to see, your AI model drafts three apps, you pick one, and the page gives you the prompt for the AI that builds it (your own connected AI, this AIMEAT's own chat, or an AI that cannot connect, which gets the whole build specification in one text). The Apps section lists the apps that show the agent's work, and the app's own page lists the agents; the tie is one row of the app's data map, it can be added to or taken from an app that already exists, and it grants no permission. The computers page names a computer, asks it what it can do, moves its agents, forgets it, gives the two commands that add one, and links to the store for a computer the operator runs when the node has a store. Limits: the sentence is turned into an agent by the AI model your account uses on this node, and that call is counted against your AI budget; when no model answers, the page gives you the same request to copy to your own AI; the page names an app or a workspace only when the agent's definition carries its address (a tool's sku, a workspace's id), and an agent that reads workspaces can open your other workspaces too; "always on" can be chosen only on a computer that keeps agents running; an agent whose definition wakes on tasks only does not read a message, and its page says so in place of the conversation; an agent is changed or removed in its settings, not on these pages; the page of one piece of work shows the result and the agent's words, and the steps, events and rating of the work stay in its settings; the three app drafts are one call to your AI model and count against your AI budget, and when no model answers the page shows one option made from your own words; the page makes no app itself, an AI does; a workspace can be chosen for an agent's work only in an organism you are an active member of; a node whose operator has saved a home layout shows the block after the operator adds it. | Home, /v1/home?new-agent=1, /v1/home?agent=<name>, /v1/home?agent=<name>&work=<task id>, /v1/home?agent=<name>&new-app=1, /v1/home?computers=1, GET /v1/home/agents, GET /v1/home/agents/choices?include=tools, PUT /v1/agents/{name}/workplace, PUT /v1/datamap/apps/{owner}/{filename}/agents/{agent}, GET /v1/prompts/build-app/agent/{name}; MCP aimeat_agent_workplace_set, aimeat_app_agent_tie, aimeat_app_agent_untie, aimeat_handbook_get { tier: "build-app/agent/<name>" } |
| Goals for your agents | You, or your own AI, give your agents a goal: what you want done in your words, when it is done, when it ends and what it may spend. Your own AI plans it with the agents you have and proposes it, and the proposal waits on your home for your one-press yes; nothing in it moves before that. When no agent or computer fits a work, AIMEAT's own model does it with your key inside the goal's spending limit: writing, a summary, a comparison, research from what the model already knows (it has no tools, so it opens no web page and posts nothing). A capable agent takes the whole goal as one open work, and agents hand the next work to each other; a coordinator agent (any of yours: your Claude chat, an outside Grok bot, a crewaimeat agent, an agent on any model) can lead it instead, or a fixed plan can. Open work is offered to every agent of yours whose tags hold a skill it asks for; the first to take it gets a task (your task-start rules apply as to any task), and after a minute the first free agent that may take it is given it. When a work is done, a reaction can start the next one, and the next task carries the results it builds on. Whatever only you can do waits for you as a step: choose, approve, answer, do it yourself with ready links and texts, or give a file or a fact; your own AI in a conversation answers for you when you tell it. Nothing is a dead end: open work nobody takes in fifteen minutes comes to you with the ways forward. The chain of work is counted and stops at the goal's limit to ask your yes, and two agents handing work back and forth stop at their own limit; an agent never hands work to itself. Pause, resume, stop, renew, add material, add subgoals that spend from their goal, ask a result again with a reason, and see before a change what running work it would end. A goal can run in rounds by the clock, only when a condition holds (a watch), or when you start one. Limits: what a goal spent counts only the model calls that went through this AIMEAT; a taken work whose started task does not move for the goal's claim time (30 minutes by default) goes back to open work, and after two tries to you; an agent runtime that does not claim open work itself is given it by the node after the minute; rounds that start when something arrives are not yet built. | /v1/goals (/waiting, /available, /{id}, /{id}/actions/{action}, /{id}/material, /{id}/works, /{id}/works/{workId}/actions/{action}, /{id}/works/{workId}/answer); MCP aimeat_goal_get, aimeat_goal_set, aimeat_goal_work, aimeat_goal_answer; live domain goals |
| Agent v2 messages and tasks | Exchange messages between principals of the same account, track work through task handles and configure delivery to a principal that is not connected. | /v1/agents/v2/messages, /v1/agents/v2/tasks, /v1/agents/v2/push-config, aimeat_v2_* |
| Tasks | Give your agents work: draft, queued, active, done, failed or declined, with events, todos, rating and webhooks. A task wakes a parked agent. An agent that should not take a request declines it and says why: you see the reason in the task list and on your home page, and it does not count as a failure. | /v1/agents/:gaii/tasks, POST /v1/agents/:name/tasks/:id/decline, aimeat_task_* |
| A task starts by itself, or waits for your OK | You decide per agent whether its tasks start on their own (it proposes its plan and goes on, and you see what was done) or wait for your OK, and you can say it differently for one task when you give it. Your basic agents start on their own from the first day. When a task waits, the answer to whoever gave it says so and why, you get a notification with a Start button once the plan is in, and the task says it in Tasks; your own AI can start it when you say "go ahead". Start wakes the agent at once. Whatever the setting, a task waits for you in person when its agent can spend money, send mail or messages in your name, delete messages as you, or delete shared workspace records, rows or a whole workspace for good (its own permission, which those deletes now ask), or when its plan says a step will spend, send or delete. You can lift that per agent: on its card, signed in yourself, you let it start work anyway with the permissions you name, paid or free, and a plan step of the same kind then goes on too; a permission you did not name still holds, and you take it back with one press. Neither an agent nor your AI can do this for you. An agent with all permissions does not keep them: your AIMEAT notes which permissions it actually uses, and after two weeks, at its next task, your AIMEAT narrows it to those and tells you in the bell and by email (switch the email off on the Email page). The task is then decided on the narrowed agent, so it starts on its own when its setting says so, and waits for you if one of the permissions it used is one of the above. You can narrow it earlier with one press on its card or by telling your AI. If the narrowing fails, that task waits for you and the next task tries again. Limits: the record of what an agent uses starts the day this ships and sees the permission checks most routes make, not every one; a permission it needs later is offered back on its card the first time it is refused. A plan's own word about what it will do is the agent's word, not checked. | Agents > the agent's card, Tasks, PATCH /v1/agents/:name/task-start, PATCH /v1/agents/:name/task-start-floor, start on POST /v1/agents/:name/tasks, POST /v1/agents/:name/tasks/:id/start, POST /v1/agents/:name/scope-narrowing, aimeat_agent_task_start_set, aimeat_task_start, aimeat_agent_scope_narrow, notification agent_narrowed |
| Stop an agent, and start it again | You can stop one of your agents for a time without removing it: on its page on your home, with the "Takes new work" switch on its card in Settings & Controls, or by telling your AI "stop the news agent". A stopped agent finishes the work it has and starts nothing new. Tasks and messages you give it are stored and wait, a scheduled run is skipped (the schedule's next run happens at its time), and its computer is not woken for new work. Its key and permissions stay, so starting it is one press and nothing is set up again. When you start it, the tasks and messages that waited go to it: a task that starts by itself starts then, and one that needs your OK goes on waiting for it. Only you, or another of your agents that may change agents, can stop or start an agent; an agent cannot do it to itself. Limits: a task sent through the agent-to-agent task interface (/v1/agents/v2/tasks, aimeat_v2_task_create) is refused while the agent is stopped, not kept; a scheduled run that was skipped is not made up; a single task that is already running is ended by cancelling that task, not by the stop; an agent built outside AIMEAT that starts work by its own timer has to read the stopped state itself, and the CrewAI package does so from 0.33.0. | POST /v1/agents/{name}/stop, POST /v1/agents/{name}/start, aimeat_agent_stop, aimeat_agent_start; stopped on GET /v1/agents |
| Reachability | An agent waiting for work over a live link counts as available, on the Agents page, in workflows and on the home card. | agent presence |
| A browser for an agent, within named sites | An agent on a computer with a browser installed can open web pages, read them and fill in fields, on the sites its definition names and nowhere else. It never sends a form: it stops at the control that would send it, and a person sends. A proposal for such an agent is refused unless it names the sites, each as a plain public hostname, so the owner approves the whole list. The new-agent page shows the sites before the owner approves, and its draft names a site only when the person's sentence names one. | aimeat_agent_propose, /v1/agents/v2/agent-proposals (crew_def.browser_domains), aimeat_crew_menu |
| Capabilities | An agent declares its MCP servers, skills, tools, domains and languages; MCP capabilities verify themselves, and the test task proves the rest. | aimeat_agent_capabilities_report |
| Directives | Set an agent's purpose, behavioural rules, memory areas and token budget, and owner-wide defaults for all your agents. Inspect the combined instructions it receives: the node's rules, then your owner-wide rules, then the agent's own. Limits: of the owner-wide defaults only the rules reach an agent; the default token budget and the default memory areas are stored and shown, but no agent receives them. | /v1/agents/:name/directives, /v1/owner/agent-defaults |
| Telemetry and activity | Agents report their model calls, which feed the usage ledger. You see what each agent did on its Activity tab and over REST; an agent reads its own figures with aimeat_agent_activity, and only its own. | aimeat_agent_telemetry_report, aimeat_agent_activity, /v1/agents/:name/activity, /v1/agents/:name/telemetry |
| Agent quality and reviews | Review completed tasks with a rating, work context, comment and source-grounding assessment. Compare task success and completion times, ratings by context and agent-published custom metrics. Small rating samples are flagged; these are observations and reviews, not service promises. You rate a task on the Quality tab or over REST; no MCP tool rates one. An agent reads its own statistics with aimeat_agent_statistics, which only the aimeat connect connector offers. | Agents > Quality, /v1/agents/:name/statistics, /v1/agents/:name/tasks/:id/rate, aimeat_agent_statistics (connector) |
| Agent usage by model and run | See an agent's reported model use, input and output tokens, cost and recent runs. Model totals and run records help explain spending; activity history shows the agent's recorded actions. | Agents > Usage and Activity, /v1/ledger/usage/overview, aimeat_agent_activity |
| Agent README and configuration files | Read the agent's own README when it has published one. Inspect, upload, edit, copy and download configuration files stored as memory records. A saved file takes effect according to the agent runtime that consumes it. | Agents > README and Agent Config, agents.<name>.readme, agents.config.*, memory APIs |
| Agent data access and linked knowledge | Inspect and edit the agent's memory, describe the areas it should use, and link knowledge resources and versioned skills. The data-area descriptions form part of its directives; scopes and consent govern actual access. | Agents > Data Access, /v1/agents/:name/data-access/overview, /v1/agents/:name/directives, /v1/agents/:name/skills |
| Agent task review and organisation | Read a task's instructions, checklist, deliverables and event history. Request changes from the agent, rate the result, or keep, archive and restore the task in the list. Asking for changes to a plan is yours, in person: an agent does not ask for changes to its own plan, so no agent tool offers it. Cancellation requests depend on the runner honouring the stop signal. | Agents > Tasks, /v1/agents/:name/tasks/:id/request-changes, /v1/agents/:name/tasks/:id/triage, aimeat_task_* |
| Agent service management | Inspect an agent's published actions, their prices, visibility, status and how often each was called; the list holds only this agent's actions, matched on its full identity. Unpublish an action when it should stop being offered: you can unpublish your own agent's actions, and nobody else's. Workspace contract engagements have their own Contracts tab. | Agents > Services and Contracts, /v1/actions, /v1/actions/:id |
| Crew builder | Build an agent crew from a template, a form or Crew JSON. Define members, roles, tools, tasks and their dependencies, skills, offers and the events that wake the crew. Inspect the task graph and edit the same definition from your AI chat. | Agents > Crew, /v1/agents/:name/crew, aimeat_crew_* |
| Crew drafts and runtime validation | Save unfinished edits for another session or discard the draft. Ask the agent's connected runtime to validate the definition and return errors beside the affected fields. Validation uses the runtime that will execute the crew. | aimeat_crew_draft, aimeat_crew_validate, /v1/agents/:name/crew/draft |
| Crew trial runs | Try a definition once with a prompt on the connected runtime and inspect its output or failure before publishing. A trial uses the runtime and its model; the node keeps its result temporarily without creating a normal task. | aimeat_crew_try, /v1/agents/:name/crew/try |
| Published crew revisions and restore | Publish a validated revision, inspect kept revisions and republish an earlier one. See which revision the runtime last loaded and any reported loading errors. A first definition can be validated by a connected sibling agent of the same owner. | aimeat_crew_get, aimeat_crew_publish, aimeat_crew_seed, /v1/agents/:name/crew/restore |
| Crew tools and model choice | Inspect the tools and model profiles offered by the runtime, with the source shown as a live answer or its last reported catalogue. Choose a model for one agent or an owner default, or clear the choice. When your model rules leave the chosen model out, the choice is saved and the answer says so. Runtime overrides can take precedence; provider credentials stay on the runner. | aimeat_crew_menu, aimeat_crew_llm_set, /v1/agents/:name/crew/menu, /v1/agents/:name/crew/llm |
| Agent modes and consoles | Set the agent's operational mode, such as task runner or workstation. Separately declare whether its runtime should start it on demand, keep it resident or leave that choice unset. The runtime must honour the declaration; the switch itself does not start or stop a process. Open the runtime's console when it reports an address. | aimeat_agent_mode_set, aimeat_agent_run_mode_set, aimeat_agent_console_set |
| Offerings for strangers | Agents with a published offering are listed at a standard address with a card saying what the work is, what it costs and what to send (the offering's input schema), so another agent can decide without starting a job. The agent's identifier is public, because its card's address names it. | agent cards, A2A, OASF |
| Built-in chat off | Chat with your own agent in the browser, with tool calls shown as they happen and file attachments. Runs a Goose process the operator installs, one per person (one for everybody when the operator sets a shared chat key), and its model calls go through your own AI providers under your model policy and budget. Within two seconds the chat says in your language what it is doing, and the agent writes a sentence between its steps. A turn that runs long answers with what it has: past 12 tool calls, 3 rounds of them or 100 seconds the agent is asked once to answer from what it found (asked for a new agent, it files the proposal and gives you the approval address), and when that also runs out, the chat ends the turn and says so. Stop and leaving the page stop the agent. The chat starts each message with about twenty tools, the ones most jobs need, and adds any other tool it may use when a job needs it (aimeat_tools_find), so a short question does not pay for the description of every tool on the server; any MCP client can connect to the same set at /v2/mcp/chat. Limits: at most 20 people's chat processes run at once, so a new one closes the one idle longest, and when all 20 are in a turn your turn is refused with the reason; a conversation idle for 15 minutes starts fresh; an operator's shared chat key skips the per-person metering, and its one process is not closed when idle. | /v1/chat, AIMEAT_GOOSE_BIN, AIMEAT_GOOSE_PROVIDER_API_KEY |
The node owns the clock, so your data can act without you present.
| Feature | What you get | Reach |
|---|---|---|
| Schedules | Schedule an extension action, an AI completion, an agent task, a connected ecosystem capability or publication to your own connected account. The server keeps the clock after you disconnect. Managed schedules can be edited, paused, resumed, triggered now or removed; removing one stops future fires and leaves existing tasks intact. You manage all your schedules; your agents manage each other's; an app manages only the schedules it made itself. Changing or running a schedule asks the same permission as creating it, for example ai:use for an AI schedule; pausing it asks none. | /v1/schedules, aimeat_schedule_* (extension, AI and agent-task creation) |
| Scheduler calendar and agent schedules | See upcoming runs in day, week and month views, including the effective time zone. Frequent jobs are summarised separately. Inspect all schedules or one agent's schedules, including extension jobs and externally run jobs that agents report. Reported external jobs are displayed; their own runtime executes them. | Settings & Controls > Scheduler, Agents > Schedules, /v1/schedules/occurrences, aimeat_schedule_report_internal |
| Schedule limits and defaults | Stop after a chosen number of successful fires, including a one-shot job, and inherit defaults from the target agent when creating a schedule. The daily USD guard checks the owner's recorded AI spending before an AI-completion job starts; it does not cap other schedule kinds or reserve the next call's cost. Limits: you set a schedule's limits and an agent's defaults on the page or over REST; a schedule your AI creates from a chat takes the target agent's defaults, and it cannot set or change a limit of its own. | POST /v1/schedules, PATCH /v1/schedules/:id (constraints), PATCH /v1/agents/:name/schedule-constraints, Agents > Agent Config |
| Schedule run history and results | Read when a schedule ran, its duration, errors, written memory keys and any task it created. Run-now responses distinguish execution or task creation from a busy, limited or failed attempt. A failed run puts a notification in the owner's bell (and web push when on); after five failures in a row the schedule is paused and the owner is told. A one-shot job that fails is turned off at once and not retried: it keeps the error, shows no next run, and the owner gets one notification. A run that does not finish within its time limit ends as an error, and the next run happens at its time. A run missed while the node was down shows in the history as missed; it is not run late. Queuing a task does not mean the agent has completed it. | /v1/schedules/:id, /v1/schedules/:id/trigger, aimeat_schedule_trigger |
| Workflows | Combine agent work, extensions, AI completions, data-package publication, exports, ecosystem-app triggers and human-input steps. Build through your AI, the form or a pasted definition, then inspect the derived graph and the memory each step reads and produces. | Workflows, /v1/workflows, aimeat_workflow_save, aimeat_workflow_get |
| Workflow triggers and run inputs | Start manually, on a cron schedule with a time zone, or on an event: a matching memory write, an offer order, rows added to a workspace row space, or an ecosystem app's event. A run an event starts knows what arrived (the key, the offer, or the row space with a count and the row ids), and an agent step gets that with its task. A rows event starts a workflow only for an owner who may read that row space. Declared variables let each run carry its own input. Dependent steps wait for their prerequisites; overlapping runs require an explicit setting, and a trigger can instead ask that everything arriving during a run starts one more run after it. The form draws the schedule, memory-write and offer-order triggers; the others are set through your AI or a pasted definition. | /v1/workflows/:id, /v1/workflows/:id/run, aimeat_workflow_save, aimeat_workflow_run |
| Workflow trigger permission check | A run its own trigger starts acts on the permissions of whoever saved the workflow. If that agent or app is disconnected, or no longer holds a permission the steps need, the run does not start: the run list shows the refusal and why, and you get one notification with two choices, run it once as yourself or approve the permission again. Workflows you saved yourself are not affected. A step that gives one of your agents work needs the saver to hold permission to give agents work; workflows saved before 2026-09-25 keep running as they were saved. | /v1/workflows/:id/runs, /v1/workflows/:id/runs/:runId/run-as-owner, aimeat_workflow_get |
| Workflow checks and preflight | Check input and output conditions against existing memory without dispatching work. Inspect agents, steps already satisfied, run variables and timeout bounds before starting. Checks have a separate history and do not count as executed runs or improve run-health figures. | /v1/workflows/:id/preflight, aimeat_workflow_run with signals-only |
| Workflow trials and output handling | A full sandbox run prefixes workflow signal and result keys and tells agents to use that prefix. It still executes work and can spend budget; external actions are not isolated. Choose whether to skip outputs already present, or explicitly clear prior workflow outputs for a fresh run. | aimeat_workflow_run with target: sandbox, workflow skip_done and fresh |
| Workflow run history and recovery | Inspect each step's outcome, output evidence, timing and the health trend across runs. Configure step timeouts and supported retries with a delay. In-flight run state survives a server restart; a cancel action stops further workflow progress. | /v1/workflows/:id/runs, /v1/workflows/:id/health, /v1/workflows/:id/runs/:runId/cancel |
| Workflow spending limit | Cap what one run may spend on AI, in US dollars: its AI steps and your model judging its worded checks count together. Before an AI step asks the model, the run sets aside what one attempt of the step is expected to cost and starts it only when that fits in what is left, so AI steps that fit together still run side by side. What is set aside stays set aside until the model answers, even when the step has already timed out, been retried or been marked done. The estimate is the most one attempt of the step cost in the workflow's last ten runs, counting only runs where the step was set up as it is now; a step with no such run gets an equal share of what is left, so its first run can still go past the limit by what it costs beyond that share. A step expected to cost more than the whole limit runs once, alone, while the run has spent less than the limit. A step that does not fit waits for the model calls still open; when none is open, the run stops, keeps what the finished steps produced and says how much was spent and what the next step would have cost. Past the limit a worded check is not sent to the model, and it passes. Each step records its own AI cost, and the run records what the judging cost. The daily AI budget still applies to every AI call. | maxCostUsd on /v1/workflows/:id, aimeat_workflow_save |
| An extension step acts on what came before | An extension step can take an earlier step's result or a person's answer as its input, so a workflow can propose an action, wait for your approval and then carry out exactly what you approved. The step names which stored results it takes; a result that is missing arrives as empty. | extension step input_from on /v1/workflows/:id, aimeat_workflow_save |
| Workflow human decisions | Pause for a person's answer, list all waiting questions and accept only the choices allowed when each question was asked. Store the answer for later steps and apply the step's timeout policy if no answer arrives. An agent can relay the owner's decision through MCP. | aimeat_workflow_pending_inputs, aimeat_workflow_answer, /v1/workflows/pending-inputs |
| Extensions | Server-side scripts in a WebAssembly sandbox, with scoped access to memory, outbound HTTP through the node's guard, secrets, the wallet and consent. Paywalls, pacing and priced actions are built in. An outbound read can inflate a gzipped answer and can return a binary answer (an image, a map file) intact as base64, and an extension that reads large files raises its own read ceiling in its manifest, up to 32 MB; the ceiling is kept on the installed extension, where your AI reads it, and the install approval does not show it. A script can give one outbound call its own time limit, so one address that does not answer does not fail the whole run, and every run ends at a wall-clock limit (twelve times its CPU limit, at least a minute), also one that only waits. Calendar arithmetic is given to a script by the node: occurrences of repeating events, free time, a time zone's local time to an instant and back, and ICS text to events and back, with the same library the browser uses, because a script has no time-zone data of its own. | /v1/extensions, /v1/ext/:name/:action, aimeat_extension_* (aimeat_extension_get returns limits), ctx.fetch(url, { gunzip: true, timeoutMs, responseType: 'base64' }), ctx.calendar.*, manifest limits.fetch_max_mb |
| Extension actions for visitors without an account | An action that says public: true in its manifest also answers someone who has not signed in, so a stranger can browse a catalogue or read a free episode. A visitor's call reads and never writes: the action's memory writes are refused, and the wallet, files, notifications, purchases, workspace, AI and mail are not there. The action knows it is serving a visitor. Every other action still needs a sign-in, and a visitor learns nothing about which extensions or actions exist. Limits: a public action takes no price and no pacing; visitor calls are counted per client address. | POST /v1/ext/{name}/{action}, AIMEAT.data.action(), manifest public: true |
| An extension names the services it calls | An extension can list the addresses it calls, and then it reaches those and no others, also when a service answers with a redirect elsewhere. The person installing it sees the list before approving. When the address is the customer's own (their own server), the extension names a setting instead: the package asks the customer for that address before the sale or the install, the extension then reaches that one address too, and the owner changes it later from their AI with no new version. One package then serves every customer. Limits: the setting holds one host name or IPv4 address, with an optional port; an address inside a private network is reached only on a node that allows private addresses. | manifest network: { hosts: [...], host_fields: { FIELD: required\|optional } }, PATCH /v1/extensions/:name/config, aimeat_extension_config_set |
| Extension hooks | Eleven lifecycle hooks: five that can refuse (owner registration, agent registration, work request, board post, federation peering) and six that are told afterwards. | /v1/admin/hooks, aimeat_admin_hook_set |
| Cortex | Installable bundles of schemas, prompts, actions, boards, ontologies, seed data and browser libraries that apps compose from. | /v1/cortex, aimeat_cortex_* |
| Install sets | Set up a customer's node in one step from an install bundle bought from a package repository: the owner user, the bundle's packages with their config, its organisms and workspaces under the customer's names, the other users and the crew agents. Each user has an email, and either gets an account now or an email invitation. A person whose account the set created gets an email naming the account, with a sign-in link that works once for 7 days; so does an owner account made before the set (by a shop, say) when its verified address is the set's, once per set; later they ask the sign-in dialog for a new link, or sign in with Google or Entra. A plan lists what would be made and what is missing before anything is created, and applying again creates nothing twice. Entitlement to the bundle also serves the packages it lists. A new node can apply its set at start-up from a file, and link the repository the set names; it tries again until the repository serves it. The repository the set names is reached and checked for updates even when package exchange with other nodes is switched off; everything else stays off. The crew agents of the bundle's apps are deployed through the owner's runner when one is connected; with no runner they wait as proposals the owner approves, and a later apply with a runner deploys them and withdraws the waiting proposal. A set the owner installs as a package proposes its agents; the operator's set deploys them. The purchase is the approval for the apps: the set records the owner's permission for each app it installs, for what the app says it uses, so the apps sign in with no question; an update that asks for more still asks, and the owner can take each permission away, which stays when the set is applied again (grant_apps: false turns this off). The owner's welcome link can open one of the set's apps, signed in (landing), and the apply record keeps the path it opens. When a set is applied to an account that existed before, that person's account feed says an operator installed it, how many packages it brought and how many apps got permissions. Limits: operator only; no screen yet. | /v1/install-sets/apply, /v1/install-sets, aimeat_admin_install_set, AIMEAT_INSTALL_SET |
| Package repository off | One node serves its private packages to the customer nodes entitled to them, and those nodes take updates from it. The customer node signs every request, so the repository knows who asks. Each entitlement says until when the node receives new versions: when the monthly updates end, the install stays and gets nothing newer. Each entitlement also follows a release channel: stable receives published versions, and beta also receives the versions the author marked beta. A shop's automation can grant a new customer node and register it in one call; such a node can pull only what it is entitled to, and nothing else in the federation: it receives no direct messages and is no home node for a sign-in. The repository registers the node only when the node's own public card shows the same node id and key. When the node is down at the moment of the sale, the sale still goes through, and the node is registered when it first contacts the repository. The operator sees how every such node arrived and who asked for it, and can remove one. Before a sale, the shop asks the repository which settings a package or bundle needs, which are required and which are secret, so the customer answers them before paying. The shop needs no token for any of this: the package's author names the shop's own AIMEAT a seller once, and the shop's node signs each request with its own key. A shop changes and revokes only the grants it sold itself; a grant the author or another shop made it may only extend to a later date, as a new sale. Changing a grant without naming a date keeps the date it had. The customer node lists what the repository offers it from a chat. An author withdraws a bad version with a reason: nothing serves it again, and every installed copy, on the repository and on each customer node at its daily check, has its extensions switched off and its owner told once; apps and records stay. The repository registers at most 500 packages-only nodes (the operator sets the limit; the Security page says when it is reached), and removes one that holds no grant and sells nothing after 30 days. Limits: the operator turns the role on, and a customer node must be the repository's peer; past about 2,000 customers of one package its grants outgrow one record. | AIMEAT_PACKAGE_REPOSITORY, /v1/packages/:groupId/entitlements, /v1/federation/packages, /v1/federation/peers/:nodeId/packages, aimeat_package_entitlements, aimeat_package_repository, aimeat_package_check_updates, /v1/packages/:groupId/config-needs, aimeat_package_config_needs, /v1/package-sellers, aimeat_package_sellers, /v1/package-sales, aimeat_package_sale, /v1/packages/:groupId/versions/:version/withdraw, aimeat_package_withdraw, AIMEAT_PACKAGE_PEER_CAP |
| Set composer | An app builder turns apps they already published into a set to sell, from their AI, in one call. An app declares the workspace it keeps its records in, in its own page; the node checks the declaration when the app is published. The composer makes one package per app and an install bundle that lists them, with the workspaces the apps declare (two apps that declare the same one share it), the crew agents they carry and the builder's default settings. A dry run writes nothing and says what a buyer will be asked, what the buyer's node must already have, what stays behind, what each part can do, and every problem; a set with a problem is refused. Composing again publishes a new version of each package and of the set, and composing one package again under its name does the same. A buyer's AI installs the set for its owner in one call: the packages, then the organism and workspaces under the owner's own names, and each installed app reads where its workspace was made. Installing again makes nothing twice. Limits: no screen yet; the builder cannot yet split the set's workspaces into more than one organism. | /v1/packages/compose-set, aimeat_package_compose_set, /v1/packages/:groupId/install, aimeat_package_install, aimeat-workspace, AIMEAT.data.appWorkspace() |
| Package sale | A person buys a package from their AI, on the AIMEAT of the shop that sells it, with the shop's ordinary checkout; they never need an account on the package repository. The package's author sets the terms once: paid, approved by the seller one request at a time, or granted at once; how many days of updates come with it; the renewal price and period; the licence, how tax is read, and a support and a security contact, which a paid offer must name. A price change makes new terms: a buyer keeps the terms they accepted, so a new price reaches only new sales. The shop sets its own price, and its operator is the seller of record; the result of each sale names the seller of record, the author as supplier and the author's price. A buyer who names the AIMEAT that is to receive the package gets it granted at once; one who does not gets a claim code (valid 30 days, works once) that the receiving AIMEAT's operator redeems, and that AIMEAT then takes packages from the repository even with package exchange switched off. The buyer renews the update service at the renewal price they accepted, or turns on automatic renewal, which keeps the card at purchase and charges it three days before the updates end; a failed charge is told to the buyer once. Fourteen days before the updates end the owner of the install is told where to renew. A sale the repository refuses is refunded where the payment method allows it, and the buyer is told whether the money came back; a payment that could not be returned is recorded for the seller, and the operator is told. The author's terms are readable only by the author, the operator and the shops selling them. The shop's operator reviews what the version on sale can do before anything sells, and a newer version that can do more waits for another review while renewals go on. An agent that searches the shop's AIMEAT finds its packages for sale, with the price and the tool that buys them. Limits: no screen yet; automatic renewal is proven with a test payment handler, not yet against real Stripe. | /v1/packages/:groupId/offer, aimeat_package_offer, /v1/package-sales/catalogue, /v1/package-sales/offer, /v1/package-sales/subscriptions, /v1/package-sales/requests, /v1/package-claims, /v1/package-sales/catalogue/review, aimeat_package_buy, aimeat_package_claim, aimeat_package_sale, /v1/discover |
| Packages | Before you install, a package says what you get: what it does for you, what to ask your AI once it is installed, its apps, what data each app keeps and where it goes (or that its author has not said), the agents it brings, what runs on its own, the operating guides your AI gets, the settings it asks and what this node must already have. Your AI reads the same sheet from a chat as the Packages page shows, and the questions of a public package before installing it. The agents a package brings wait as proposals among your open items: approving one creates the agent with what it does and the permissions the app declares for it, and nothing runs before you approve. Install versioned bundles with a dry run and rollback on failed installation. Track installed instances, check for updates, detect local customizations and use a migration prompt before applying an update. When an agent or an app installs a package that writes entries into your memory and it lacks the permission to, the install waits for you instead of failing: one notification with Approve and Decline, which installs it as yours. An agent of yours that holds the permission can approve it from a chat, never its own request. A request you leave undecided expires after seven days. A package can also be installed as managed: the package then owns the code and layout of what it installed, an update replaces them, and you change only the settings (name, description, access code, parking, search visibility, legal texts). When you want to change the code yourself, you fork the install: it becomes yours to edit at the same addresses with the same data, and it receives no more updates. An install fills in each part's config, so the apps work at once: the values an app declares it needs (a company name, a currency) and an extension's own config, where an API key is stored encrypted. Your AI runs a dry run first, sees which values are still missing and asks you for them. A package that needs an extension or library this node does not have says so before anything is installed. A package never overwrites a record you already have, and never replaces somebody else's structure lock on this node; it is refused before anything is installed. Before you install, the package also says what each part will be able to do: what an extension reaches on the internet, which secrets it asks for and what it runs on a schedule, which permissions an app asks for, which structure locks it sets and which instructions your AI gets, and who made it and where it came from. An agent installs a package with code only when you gave it that permission; otherwise you get a request with the same list to approve. Installing a package is approving its apps when the package is your own: they sign you in with no question. For someone else's package your AI shows what each app asks for, and you choose: approve them now (grant_apps), or let each app ask for your consent on its first visit like any other app. An agent approves an app only for permissions it holds itself; an app that asks for more asks you. On the Packages page, an opened package says what each of its apps asks for; for someone else's package you tick "Approve the apps now", or leave it and each app asks on its first visit. An automatic update that would let the package do more than you approved waits for you. A package made from your apps carries your skills bound to them, so the AI of whoever installs it gets each app's operating guide; a skill of the same name the installer already has stays theirs. It also carries each app's tool list and data map: the installer's AI can call the same tools on their copy, and the sheet lists the tools before installing. Prices stay with the seller: the tool list travels without them, and the installer prices their copy's tools themselves if they sell them. A tool list the installer already has for that app stays theirs. Every day the node checks the nodes your packages came from: a newer version is brought in, and an install with automatic updates on is updated, while the others tell you an update is ready. You turn automatic updates on or off for each install on the Packages page or from your AI. Parts you edited stay as they are either way. | /v1/packages, /v1/instances, PATCH /v1/instances/:id (auto_update), aimeat_package_instance_set, /v1/instances/:id/fork, /v1/package-install-requests, aimeat_package_* |
| Tracked responses | A promised reply that goes out once a memory key meets a condition. | /v1/tracked-responses |
| Signals | Count something: define it and record hits from a tracking image or a JSON call. A stream can also keep where each person came from, at the precision its owner picks (country, region or city). That needs a reverse proxy that reports the place (AIMEAT_GEO_HEADERS, visitor-geography.md); no address is stored, and AI fetchers are never placed. | /v1/signals |
| How people and AIs find you | See, for your whole place and with no setup, where the people who open your apps, portfolio and company page came from (an AI answer and which AI, search, social, another site, or direct), which AI fetched which page because a person asked it or to build its index, who read your llms.txt, AGENTS.md, MCP card and UCP profile, and which completed purchases came from which channel, including purchases an AI agent made at your checkout. You read it on the Visibility page in Settings, and your own AI reads the same report and can answer "why did sales drop". Counts only: no address, no cookie and no visitor id is kept, so it is on by default without a consent banner; a browser that sends Global Privacy Control or Do Not Track is counted in the total alone. You can switch it off for your place, and the operator for the node (AIMEAT_AI_VISIBILITY). Limits: the questions people asked the AI are not visible, only what the AI fetched; a purchase is placed in a channel only when the page that opened the checkout used the commerce library or an agent opened it; counts reach the report within ten seconds, and a node stopped without warning can lose the last ten seconds. | Settings > Visibility, GET /v1/visibility/report, /v1/visibility/settings, aimeat_visibility_report, aimeat_visibility_settings_set |
| Where AI agents stop | See where AI agents give up at your place, which a browser script cannot show: how many checkouts each AI's agents started, changed, completed, abandoned, let expire or failed, the error each failure answered and the step it stopped at, and how many calls other people's agents made to your tools, with the ones refused or failed by tool and reason. The report says it in one line per finding, for example "A copilot agent tried to buy 14 times; 9 checkouts failed at payment (PSP_ERROR), 2 were abandoned, 3 completed", and your own AI reads the same lines. An agent is counted by the AI it is (from its UCP profile, its User-Agent or its name), never by its name; an error is kept as its code, never its message or input. Your own agents and people are not counted here. Limits: a tool call is counted when it goes through the node's metering (app tools, extensions and exchange work that name you as the seller, and your attached MCP servers); at most 100 kinds of error a day. The operator can switch it off for the node (AIMEAT_AGENT_EXPERIENCE). | GET /v1/visibility/report (agents), aimeat_visibility_report |
| What people do on your apps | See, for each of your apps and with no setup, where people click, how far they scroll, which clicks on a button changed nothing (dead clicks) and where they clicked again and again (rage clicks), by phone, tablet and computer, with one line per finding such as "On phones, 14 clicks on button#buy changed nothing on the page." Your own AI reads the same findings. Switch on the weekly fixing agent and it asks your own AI for a corrected app from those findings and writes it as the app's draft: it never publishes, the live app stays as it is until you publish the draft, and a draft you wrote yourself is left alone. You get a line on your home page when a draft is waiting. Counts only: no address, cookie, visitor id, keystroke, input value, page text or recording; an element is named by its tag, id and first class; a browser that asks not to be followed counts as a view only. Limits: the fixing agent is off until you switch it on, and every run spends your AI credit; it works on HTML apps up to 120 000 characters; seven days of findings feed a run, and 56 days are kept; a dead click is a click after which nothing on the page changed within a second, so a button that works slowly can show as dead. Switch the script off per app; the operator can switch it off for the node (AIMEAT_BEHAVIOUR). | Settings > Visibility > On your apps, GET /v1/visibility/behaviour, GET/PUT /v1/visibility/behaviour/settings, POST /v1/visibility/behaviour/fix, aimeat_visibility_behaviour, aimeat_visibility_behaviour_set, aimeat_visibility_behaviour_fix |
| Bring your own Clarity or Google Analytics | Give your Microsoft Clarity project id or your Google Analytics 4 measurement id, and the place adds that tag to every app, your portfolio and your company page; the data goes to your own account. When the node shows a cookie banner, the tag loads only after the visitor accepts analytics, and the choice is passed on to Clarity and Google (advertising storage is always denied). Without a banner the tag loads at once, and the settings answer and the report tell you that EU visitors need consent first. A browser that sends Global Privacy Control gets no tag. The operator can switch the feature off for the node (AIMEAT_ANALYTICS_TAGS). | PUT /v1/visibility/settings (clarity_project_id, ga4_measurement_id), aimeat_visibility_settings_set |
| Sell through AI shopping agents | Your public offers and app tools with a USD price become a product feed for Microsoft Copilot Checkout: add the feed address to your own Merchant Center account ("Automatically download file from URL"), and the next daily fetch carries any price you changed. The same products go into your own Stripe as an agent-commerce catalog with one call, and when an AI agent buys through Stripe, the order lands here with a task for the agent or the app that delivers it. The feed tells you what is listed, what was left out and why, and what you still have to do (a return policy label, a page per product). Limits: Copilot Checkout is for US buyers in USD; Microsoft has not said whether digital products qualify, so your own Merchant Center validation is the answer; packages are not listed, because a package installs on a node; Stripe's agent-commerce catalog is a Stripe preview; your own Merchant Center and Stripe accounts are used, never the node's. | GET/PUT /v1/visibility/feed, POST /v1/visibility/feed/stripe-sync, /v1/visibility/feeds/{owner}/merchant-center.txt, /v1/visibility/feeds/{owner}/stripe-catalog.csv, aimeat_visibility_feed |
| AI platforms buy here directly (UCP) | An AI shopping platform such as Copilot or Gemini can buy your offers and app tools for a person who has no account here, through your place's own Universal Commerce Protocol checkout (version 2026-08-25): it opens a checkout, gives the buyer's email, and pays with a Stripe shared payment token that is charged on your own Stripe. The order lands with your other orders, each line becomes a task for the agent or the app that delivers it, and the platform is told about the order and about each delivery in signed messages it can check against this node's published key. A signed request from the platform is checked against its own published keys. Limits: USD only; packages are not sold this way; payment needs your Stripe network profile id (stripe_profile_id) and Stripe's agent payment handler, which is a Stripe preview; a message the platform does not take is tried again for about two days. The signed-in checkout for AIMEAT accounts stays at /ucp/v1 (version 2026-04-08). | /.well-known/ucp, /ucp/2026-08-25/checkout-sessions, /ucp/2026-08-25/orders/{id} |
The owner brings their own model key; the node meters and fences its use.
| Feature | What you get | Reach |
|---|---|---|
| AI completions for apps and agents | Anyone with ai:use gets completions on the owner's providers, under a daily USD budget, a per-app quota and a provider allowlist. A call may carry pictures, and files or PDFs that the model reads itself. In an app that calls through the AI library (AIMEAT.ai), repeat clicks on a paid button collapse into one call; the node itself runs every request it receives. On the node's own key, each person spends an AI allowance; once it is used up, the operator decides what the key does: it pays for nothing more (the default), or it keeps paying up to a daily cap per account and a daily cap for all accounts. | POST /v1/ai/complete, POST /v1/ai/stream, /v1/ai/usage, GET/POST /v1/ai/settings (the daily budget, the per-app quotas and the app allowlist), AIMEAT_AI_NODE_KEY_WHEN_SPENT, AIMEAT_AI_NODE_KEY_ACCOUNT_DAILY_USD, AIMEAT_AI_NODE_KEY_NODE_DAILY_USD |
| AI capabilities | Your AI, an app or an agent asks one question first: what can I do here? For text, reading pictures, reading files, making pictures, speech, transcription and embeddings, the answer says whether it is on, which model and provider would answer and at what price, and for one that is off, what to do about it: a sentence for you in your language, and a link that opens your AI settings at the provider to fix, with its test chosen when a test is what turns it on. A refused AI call carries the same sentence and link, so an app shows them instead of an error code, and your AI can offer to run the test for you. An app states its needs in its AI meta (the models it needs, the providers it prefers, what must stay on your machine), and the publish check warns its builder about a capability used without checking first. Speech and embeddings get a model and a voice from your provider, from you or from the operator. Your AI can transcribe a stored recording and make embeddings. The AI page in Settings & Controls shows your providers, which one answers each capability, and your model policy; above the providers it lists what is off and why, and a provider that is not tested yet has Test now on its row. Limits: a crew uses the node's AI through node_llm() in the aimeat-crewai package. | GET /v1/ai/capabilities, POST /v1/ai/transcribe, POST /v1/ai/speak, aimeat_ai_capabilities, aimeat_ai_models, aimeat_ai_transcribe, AIMEAT.ai.capabilities(), AIMEAT_MODEL_DEFAULT_TTS, AIMEAT_TTS_VOICE_DEFAULT |
| Embeddings | Text turned into vectors, so a search finds what means the same, not only the same words: meaning search in a large collection, similar items, duplicates written in different words. Only the same model ever answers a fallback, because vectors of two models cannot be compared, and the answer names the model to store beside them. The guide says when not to use them: a few hundred texts, exact values, or just in case. Limits: at most 256 texts per call; the node has no vector search of its own yet. | POST /v1/ai/embed, aimeat_ai_embed, AIMEAT.ai.embed(), AIMEAT_MODEL_DEFAULT_EMBED |
| AI providers | Use your own accounts at OpenAI, Anthropic, Mistral, xAI or OpenRouter, a model server on your own machine, any OpenAI-compatible address, or an extension you installed that serves AI calls for a service the node has no built-in support for, side by side. An extension provider runs in the sandbox; the node adds your key to its requests, only to the hosts its manifest lists, so its code never sees the key. For each provider you say which capabilities it serves (text, images as input, files, making images, speech, transcription, embeddings) with which model, and whether the node may pick it by capability alone. Keys are encrypted at rest, set only on the web page and never shown again. Your AI lists the providers and tests one with the smallest real call. The node's own key belongs to the node's own OpenRouter provider and never reaches an address a person or an app named. The setting you had before becomes a provider on its own. A model the catalogue does not list for that capability is refused when you set it, one it does not know gets a warning, and the list shows a model that is retiring or retired. On the AI page in Settings & Controls you add a provider, set or remove its key, turn its capabilities on with a model each, set the speech voice, the transcription language, OpenRouter's PDF engine and the default fine-tuning of text (which an app's own overrides), test it and delete it. Your own OpenRouter key thinks with the node's default model until you choose one. A free model is used only when you choose it, or when your key has no credit left: then a text call that named no model is tried once on OpenRouter's free models, if your model policy allows them. | /v1/ai/complete, /v1/llm, GET /v1/ai/providers, PUT/DELETE /v1/ai/providers/{id}, PUT/DELETE /v1/ai/providers/{id}/key, POST /v1/ai/providers/{id}/test, aimeat_ai_providers, aimeat_ai_provider_test, AIMEAT_AI_PROVIDERS, AIMEAT_AI_BUILTIN_PROVIDERS, AIMEAT_AI_PROVIDER_TYPES |
| Routing and fallback | Say which provider answers each capability, in order, and the node tries the next when one times out, is rate limited, fails or refuses its key. It never moves on for a bad request or refused content, never after a stream has started, and by default never from a model on your machine to one outside it. A provider that fails three times in a row is gone round for five minutes; each answer says who chose the provider, who answered and every attempt, and each attempt is a line in your usage. Your AI proposes a change and you confirm it; on the AI page in Settings & Controls you set the order and the rules yourself. The settings routes from before providers (/v1/openrouter/settings, /models and /test) answer 410 since 4.0.0 and name /v1/ai/providers instead. | GET/PUT /v1/ai/routing, aimeat_ai_routing_set, route on /v1/ai/complete, /v1/ai/image, /v1/ai/transcribe |
| AI roles | Say what a model is used for, not only what it does. A role (a writer, a summarizer, an illustrator) names the capabilities it needs and, for each one, your providers and models in the order to try them; you make your own, and two built-in ones, reasoning and execution, carry what your agents' crews used before. An app declares the roles it needs in its AI meta, with what each is for and its own fine-tuning, and never names a model, so it works on any providers you have. An app's role runs only after you connect it to one of your roles: until then its calls are refused and you see the request, with what the role needs, on the AI page. Your AI proposes a role or a connection and you confirm it. Each role shows when it was last used. Limits: an agent runs as your roles, not as roles of its own; a role's order is up to five providers per capability, one place each. | GET/PUT /v1/ai/roles, role on /v1/ai/complete, /v1/ai/image, /v1/ai/transcribe, /v1/ai/speak, /v1/ai/embed, aimeat_ai_roles, aimeat_ai_role_set, role.<name>= in <meta name="aimeat-ai"> |
| Model policy and recommended models | Keep weak models out of your work. Choose the models the node recommends (the operator's list, which follows new versions) or a list of your own, and say whose calls it covers: your own, the chat, your agents, your apps; tighten it further for one app or one agent. An app may limit itself with models= in its AI meta. A call that names a model the rules leave out is refused with the allowed models listed, and a call without a model gets the first allowed one and is told so. Every layer can only tighten. Your AI proposes a change and you confirm it. Limits: a model is written <type>:<model id>, and a model of your own list that the catalogue does not know is taken to be a text model. You set the policy on the AI page in Settings & Controls, through the API or by your AI. | GET/PUT /v1/ai/policy, GET /v1/ai/recommended, aimeat_ai_policy_set, AIMEAT_AI_RECOMMENDED_MODELS |
| Model catalogue | The node knows what each model of OpenRouter, OpenAI, Anthropic, xAI, Mistral and DeepSeek takes and gives, its limits and its price, from three public sources (models.dev, OpenRouter, LiteLLM) and refreshed weekly. From it: what a call costs when the provider does not say, recorded with the catalogue version it came from; the same model at another provider when the routing falls back; and which model of your own list serves a capability. A model the sources stop listing is retiring, then retired after four weeks, and the operator is told when a recommended model retires. A new node starts from a bundled copy and works without the network. Limits: a model on your own machine is not in it; an audio price whose unit the sources do not state is never guessed. | GET /v1/ai/models, GET /v1/ai/catalog/meta, POST /v1/admin/ai/catalog/refresh, pnpm ai:catalog:refresh, AIMEAT_AI_CATALOG_REFRESH, AIMEAT_AI_PRICE_OVERRIDES, AIMEAT_AI_CATALOG_SOURCES |
| OpenAI-compatible proxy | Outside agents call the node like an OpenAI endpoint and spend under the node's rules. | /v1/llm/chat/completions, /v1/llm/models |
| Background AI jobs | Start a long AI job (a text answer, a picture or a transcription), get a job id at once, and read or cancel it later. The job runs on your own key and daily budget, with no limit on the answer's length (the answer-length setting on your AI page does not apply to it), and a text job's record says when the provider still cut the answer short. It writes its answer to a memory key you name, and can call one of your extension actions when it is done. That action gets the answer with the call (up to 64 kB), and an extension reads the answer of a job it started at any later time with ctx.ai.result, so the answer stays private to you. | POST /v1/ai/jobs, GET /v1/ai/jobs, GET /v1/ai/jobs/:id, POST /v1/ai/jobs/:id/cancel, aimeat_ai_job_* |
| Decision model | A second kind of AI beside the text model: ask closed questions (yes or no, pick one, a scale) about a record and get typed answers with probabilities, to sort, screen, route or gate. Personal data (e-mails, phones, Finnish identity codes, IBANs, street addresses, names) is removed before anything is sent and put back into the answer. Every decision is recorded with the model version, the thresholds and whether a person reviewed it, so the owner can ask what was decided about a record. Runs over many records resume where they stopped. An app must name TypeSafe in its data map first. What an app sends is the app's responsibility; the publish check warns its builder where it departs from the rules. The owner's own TypeSafe key, or the node's from the AI allowance, each testable with one press (owner in AI settings, operator in the admin Config tab); questions must be written in English. | POST /v1/ai/decide, /v1/ai/decisions, /v1/ai/decide/runs, /v1/ai/decide/settings/test, /v1/admin/decide/test, aimeat_decide, aimeat_decision_*, aimeat_decide_*, aimeat-decide |
| Decision rules | Write a judgement once and let both your apps and your agents run it by name: a set of questions, a threshold for each question that counts, and two bands that turn the answers into act, ask a person, or stop. The caller sends only the content to judge and cannot change the questions or the numbers. You say whether a rule is for agents, for apps or for both, and the server holds every caller to it. An agent may propose a rule; nothing exists until you approve it from your open items. Each rule shows how many decisions it made, how many a gate stopped, how many a person changed, and what they cost, which is what you tune the thresholds from. Limits: the questions are written in English, a rule needs at least one threshold, and no numbers are suggested for you. | /v1/ai/decide/rules, /v1/ai/decide/rules/{id}/try, /v1/ai/decide/rule-proposals, /v1/ai/decisions/stats, rule on POST /v1/ai/decide, aimeat_decide_rules, aimeat_decide_rule_propose, AIMEAT.decide.rule(id) |
| A gate per agent | A decision rule that guards an action that cannot be undone is a gate. With the gate on for an agent, an answer the model is not sure enough about becomes a task on your list and the agent is told not to act. With the gate off the agent acts and the decision is still recorded with the same outcome. It is off until you turn it on, so that you can first compare how the agent does without it. Limit: the server tells the agent not to proceed; it does not perform or block the action itself. | the agent's page (AI keys, cap and gate), PUT /v1/agents/{name}/ai-keys |
| Decision providers | Choose who answers your decision questions. TypeSafe's Jev is the default; a local decision model on your own machine answers the same questions with no key and no cost, and your content does not leave the machine (personal data is still removed first). You may add a provider of your own address and key, set your default, and give each agent its own; a rule may name the provider it always runs on. Each provider carries its limits, and a question it cannot carry (too many options, too long a text) is refused before anything is sent, naming the provider and its number. Every decision records which provider answered, and the quality numbers group by provider. Limits: only you, signed in yourself, add your own provider or choose your default, on the Decision model card in your settings or through the settings API; your AI can list the providers and name one per question; on a public node, a local model is one the operator runs and names by its exact address (AIMEAT_DECIDE_PROVIDER_EGRESS), so the node reaches that model and nothing else on its own machine; your own provider at a local address works only on a development node. | GET/PUT/DELETE /v1/ai/decide/providers, provider on POST /v1/ai/decide and on runs, PUT /v1/ai/decide/settings (provider, agent_providers), group_by=provider on /v1/ai/decisions/stats, AIMEAT.decide.providers() |
| A key per agent | Give one agent its own TypeSafe key and its own OpenRouter key, so that its spending is separate from yours, with a daily cap beside it. A call pays with the agent's key first, then yours, then the server's, and every decision records which one paid. A key is never shown again and never sent to the agent; for an agent that makes its own calls on your computer you give the name of the environment variable instead. The same order holds for the decision model, text completions, the OpenAI-shaped door and background jobs: your agent's call is paid from your account, under your daily budget, in the agent's name, and pictures and transcripts follow the same order. The chat status and the AI capabilities say what your own key reaches on this node and what it does not, agent by agent, and the AI page says the same in words. Choose "think through the node" for an agent's crew and its model calls come to this node with the agent's own credential, so the agent's key, then yours, then the node's pays, under your budget and the agent's cap. It is the default for every agent that may use AI here, when this node has a key to pay with (yours or the place's); an agent without that permission keeps the key on the machine that runs it, even when your default says the node. The runtime reads which choice applies from the node. A model choice that names a key variable is refused unless the variable is a provider key and every address is public https, because the crew sends that key there. Limits: a crew that calls its model itself uses the key on the machine that runs it, not yours, until its runtime takes the node choice; the basic agents created before 2026-10-02 need the ai:use permission granted first. | /v1/agents/{name}/ai-keys, /v1/agents/{name}/ai-keys/{model}/test, GET /v1/agents/{name}/crew/llm, /v1/chat/status (own_key), aimeat_ai_capabilities (own_key), aimeat_crew_llm_set ({kind:'node'}), aimeat_agent_runtime_report (llm) |
| Image generation | Generate an image and store it. It is paid like text: an agent's own key first, then the owner's, then the node's allowance when the operator named a default image model. Every picture carries a provenance record that names it by the SHA-256 of its bytes, and the stored file names that record, so a public picture is served with its AI marks and its record answers anyone. The REST answer gives the picture's real type (PNG, JPEG, GIF or WebP) with its width and height. The MCP answer gives the type, the cost and the record's id, without the width and height. Up to 16 reference pictures go to the model as pictures, so a character, a place or a style stays the same from picture to picture: a character sheet, the setting, the previous page, a style sample. A mask redraws part of the first reference and keeps the rest. An agent can use its own files and the pictures it made earlier, never its owner's other files. A picture an agent asks to make public meets the publish gate as an uploaded file does: without your permission it is saved private and you get the request, and the answer's address opens for everyone once you approve. Limits: the model must take pictures as input; OpenRouter and xAI have no mask parameter, so there the model follows the mask as one more picture and the answer says so (mask_mode: guided); an extension provider takes no reference pictures; pictures sent inline count against the request size limit (15 MB by default), stored ones only against 40 MB in all. | /v1/ai/image (reference_images, mask), aimeat_image_generate, AIMEAT.ai.image |
| Speech to text | Transcribe audio on the owner's configured speech model and AI budget, paid in the same order as text (the node's allowance only when the operator named a default transcription model). Every transcript carries a provenance record that says a model transcribed it, and a detailed call returns the provider's timed segments. Browser speech synthesis remains available through the speech library. | /v1/ai/transcribe, aimeat_ai_transcribe, aimeat-speech |
| Voice conversations | Apps can listen, generate a reply and start speaking before the full reply is ready. Configure models, silence detection, sentence chunks, buffering and interruption, or replace a stage with an adapter. Requires microphone consent where used, ai:use and a compatible configured provider. PCM plays incrementally; MP3 buffers a segment. The answer says what the audio is: its type and, for PCM, the sample rate, channels and sample format (24 kHz, mono, 16-bit for OpenAI-compatible providers). Speech follows your provider order and moves to the next provider before the first byte; a voice the model does not have is refused before the paid call, with the model's voices listed. Agents can request final text or a private audio file, which remains until deleted; the file names the provenance record made for its bytes, so made public in place it carries its AI marks. Configuration and limits. | aimeat-voice, /v1/ai/stream, /v1/ai/speak, aimeat_voice_reply, aimeat_voice_speak |
| A provider's refusal says why | When an AI provider refuses a call as it was sent (a model that does not make mp3, an unknown option, a file too large), every AI route answers 422 with the provider's own reason, so the caller changes the call instead of retrying it. Moderation refusals, a provider account with no credit and a rate limit each have their own answer, the last with the provider's wait time; only the provider's own fault says to try again. A refused mp3 suggests pcm. The provider's text is shortened and has anything that looks like a key removed. | PROVIDER_REJECTED, CONTENT_REFUSED, PROVIDER_NO_CREDIT, RATE_LIMITED on /v1/ai/*, /v1/llm, the aimeat_ai_* and aimeat_voice_* tools |
| Living document authoring | Your model drafts an interactive document template from a plain request. The route only returns the template and saves nothing; the Document templates page saves it as a record you can edit. Owner only. | POST /v1/living/author, Profile › Document templates |
| Prompt calibrator | A workbench for tuning a prompt through generate, analyse, reflect and synthesise batches. | /v1/calibrator |
| Managed prompts | Build specs and tier prompts are served by the node, versioned and editable by the operator. When an update ships a new default text, a prompt the operator never changed takes it at the next start, and the start log names each one; a prompt the operator changed keeps their text. A stored text counts as unchanged when it is exactly one of the texts that prompt has shipped with, or when its newest version is a factory write; a shipped text the operator restored on purpose is kept. | /v1/prompts/*, /v1/admin/prompts |
An app is a single-file web app hosted by the node. It reaches the owner's data only through the APIs, under a grant the owner approved.
| Feature | What you get | Reach |
|---|---|---|
| Publish from a chat | Your AI publishes an app. The publish answer gives the app's file address on the node; the address people open, name.apps.<node>, comes from the app list or the app's own details. Any AI chat can build from the node's build spec; no connector is required. | How an app builds, /v1/apps, aimeat_app_publish, aimeat_app_list and aimeat_app_get (url) |
| Edit with AI | Describe a change, preview the proposed app and choose whether to keep or discard it. AI editing uses the owner's configured model; publishing remains a separate action. A preview (a proposal, a working copy, a checkpoint) runs in a sandboxed frame and signs in with the app's own grant, never with your session; the code of an app that is not yours gets nothing until you agree in the consent window. Only the app's owner sees this section. | App Catalog > app details > Edit with AI |
| Saved working copy and checkpoints | Save an unpublished working copy on the node so it survives a reload. In the App Catalog, each save keeps the copy it replaced as a checkpoint with its change note, which you can restore; the newest 8 are kept per app. Limits: a checkpoint is one memory record, so an app larger than about three quarters of the node's record size limit (1 MB by default) gets no checkpoint, and the save still goes through; a working copy your AI saves keeps no checkpoint. Only the app's owner sees the working copy and its history in the App Catalog; somebody else opening the app gets its source read-only, with no save or publish. A working copy can carry one sentence on what it changes, which the people who build the app see on the app itself (see "What is new in an app, on the app"). | App Catalog > Working-copy history, aimeat_app_draft_* (notice) |
| Staging preview | Open a saved draft on its staging origin through a preview token and try it before publishing. The draft can carry the version number people see (for example 1.4.0), given when you save it or when you publish it; without one it keeps the live app's. | App Catalog > staging preview, aimeat_app_draft_* (version on aimeat_app_draft_save and aimeat_app_draft_publish), PUT /v1/apps/{owner}/{filename}/draft, POST /v1/apps/{owner}/{filename}/publish-draft |
| Published versions and restore | Read the publication history, open an earlier version, restore it or fork it. The Versions section groups publishes into sittings (publishes less than two hours apart), draws publishes per day, and estimates the work as the time between the publishes of each sitting; what happened before a sitting's first publish is not counted. | /v1/apps/:owner/:filename/versions, aimeat_app_manage action versions, App Catalog > Versions |
| Checked before it goes live | Every publish checks the app first. A script that does not parse, a script or stylesheet the node cannot find, or an Atelier app that names no committed look stops the publish. Theme colours written past the theme, missing head declarations and data reads that name no owner come back as warnings in the publish answer, with the page that explains each fix. | POST /v1/apps, aimeat_app_publish, aimeat_app_draft_publish (422 APP_ARTIFACT_BROKEN) |
| Build spec with a token | The canonical build prompt hands out a token; the publish says whether the app was built against today's spec. | /v1/prompts/build-app, /v1/prompts/build-app/core (the part every app needs; the rest by section), aimeat_handbook_get { tier: "build-app" } over MCP, /v1/prompts/build-app-atelier and its parts (/v1/prompts/build-app-atelier/sections/{id}, aimeat_handbook_get { tier: "build-app-atelier" } over MCP), /v1/how-an-app-builds |
| Its own origin | Every app runs on its own subdomain, so a broken or hostile app cannot reach your session on the main site. A node that several people share and that has no app subdomains runs every app in an isolated frame on its own address instead: the frame's origin is opaque, so the app reads nobody's sign-in, and it gets only its own grant through the node's page around it. Apps that use the served libraries work there unchanged, localStorage included; IndexedDB, service workers, push and installing need an app subdomain. A node one person uses runs that person's own apps on its own address, and an app a package installed in the isolated frame, so a bought app never holds the owner's session; the Security page says how to give apps addresses of their own, which every node should have. An app signs a person in with AIMEAT.auth.signIn(): a window on the node, where they sign in or create an account (signIn({ register: true }) opens it on the create-account form) and approve the app once; after that the app signs them in with no click. An app never signs anyone in itself: with the operator's setting on, sign-in, account creation and the session refresh refuse a request from an app. Limits: the setting is off during the rollout, and then such a request is only logged. | *.apps.<apex>, /v1/apps/:owner/:filename?mode=inline, AIMEAT_APP_ORIGIN_SIGN_IN_REFUSE |
| Fork and lineage | Allow others to fork an app, create a fork and inspect its recorded ancestry. The fork has its own owner and publication history. | aimeat_app_fork, aimeat_app_manage actions settings (forkable) and lineage, App Catalog > fork permissions and lineage |
| Copy protection options | Choose obfuscation, a domain lock, a watermark or refusal of raw downloads. The setting applies to every version of the app, older ones included. These affect distribution and execution; they cannot make browser-delivered code impossible to copy. | aimeat_app_manage action settings (protection), App Catalog > Protection |
| Listing and access codes | Choose who sees an app in a list. Listed: everyone, including search engines. Community: only people signed in to this node, in the catalogue's Community list, and their agents; the public catalogue, search engines and other nodes do not show it. Unlisted: only you. Set, change or remove an access code for opening the app. The code, the pacing amount and the copy protection you set now apply to every earlier version too. An AI asking for an app's details (aimeat_app_get) gets them only for an app it may see; any other app is answered as not found. | PATCH /v1/apps/:filename (listing), aimeat_app_manage action settings, App Catalog > Manage on server |
| Who may open an app | Listing says who sees an app in a list; this says who may open it. Anyone (the default), signed-in (people with an account on this node, and their agents and apps), or the members of one organism you belong to. Someone who opens the link without a session is asked to sign in and comes back to the app; someone outside the organism is told the app is not open to them. You and an operator always open it, an access code still applies on top, and a new version keeps the setting. In the app catalogue you set it under Manage, beside the listing, and the app's page says in one sentence who can open it. The operator sets how a NEW app starts: its listing, who may open it, and whether it gets a generated access code, which the publish answer tells you; a fork starts the same way, without a code. Your welcome page and a company's front page take the same three choices and the same sign-in step; a search engine never lists a page that is not open to anyone. | open_to on PATCH /v1/apps/:filename and aimeat_app_manage action settings, open_to on GET /v1/apps (the level only for anyone but the owner), POST /v1/apps/:owner/:filename/open, /v1/app-open, apps.default_listing, apps.default_access, apps.default_access_code; for pages access on PUT /v1/portfolio/config, aimeat_portfolio_publish, PUT /v1/companies/:id/front-page and aimeat_company_front_page, POST /v1/portfolio/:username/open, POST /v1/companies/:id/open |
| Screenshots, icons and promotion | Update an app's screenshot and PNG install icon, and edit its name and description. Promote your own published app with a short pitch in English and Finnish: it shows in the Promoted apps part of your public portfolio, and it is kept as one public record in your memory (app-catalog.promoted), not as a place in the catalogue. The node can photograph the app itself. A page the node opens this way reaches the node and public addresses, and no private address unless the operator lists that server. | /v1/apps/:owner/:filename/screenshot, /v1/apps/:owner/:filename/icon, aimeat_app_manage actions screenshot, screenshot_upload, screenshot_clear and settings (name, descriptions), security.screenshot_egress (AIMEAT_SCREENSHOT_EGRESS), App Catalog > About and Promote |
| Backup and restore | Download a ZIP of every version of your apps and your own cortex extensions, inspect it, restore what you choose. A restore applies the checks a publish and an install apply: your app limit, the access code and settings of the app it adds to, and your own namespace for an extension. | /v1/apps/backup (with ?to=storage an agent holding app:write writes the ZIP to private storage), aimeat_app_manage action backup_export; restoring is the owner's own act in App Catalog |
| Search engines only if you say so | Each app has a Search section, off by default. Turned on, the app joins the sitemap, invites crawlers and notifies the engines that accept instant updates, and its name and description appear in the text the front page and the store send to a search engine that does not run JavaScript. A shared link shows a preview card with the app's screenshot. The operator can stop the node from pointing search engines at its apps at all. The apps then leave the sitemap index and no engine is told about them, and every app stays reachable. | aimeat_app_manage action seo, seo.announce_apps (AIMEAT_SEO_ANNOUNCE_APPS) |
| App legal pages | Write or link terms, privacy, imprint, refunds, accessibility, cookies and support pages under the app's own address. The details view identifies recommended pages that are missing. | /v1/apps/:owner/:filename/legal, aimeat_app_manage action legal |
| Visitors | See who opened your own app over the last 0 to 360 days: opens by signed-in people against opens by nobody signed in, as counts and never as names. Switch visitor measurement on to also count people against named AIs against other bots, and to see where people came from on a world map drawn from the node's own files. Measurement is off until the app's owner switches it on; switching it off keeps what was counted. The place needs the reverse proxy described under Signals. A record that a signed-in person opened an app names their account for 13 months; after that a nightly job keeps only counts without names, per app and per day. | /v1/apps/visitors, aimeat_app_manage actions visitors and visitors_measure, App Catalog > Visitors |
| Marks and authorship | Set the app's marks and authorship information: the "publish your own app" badge, the install offer, the "Use with your AI" mark, the app-info mark, and whether the marks start tucked away for a visitor (in view unless you choose; a visitor's own choice wins; the AI label and the cookie mark always stay). Naming the person responsible for an app is a separate declaration with its own approval rules. | aimeat_app_manage action marks (badge, install, aiUse, info, tucked), App Catalog > Marks and authorship |
| Open one app in the App Catalog | A link names one app and opens its details in the list it belongs to: Your apps when it is yours, Building for others when you hold a development right on it, the community's otherwise, signed in or not. The search finds an app by its file name too. While the details are open, the top bar stays in reach, so you sign in and out without closing them. Somebody else's app shows the parts anybody may use (versions, sharing as a prompt, the source to read, what it needs, its skills and roadmap) and none of the owner's controls. | /v1/appcat?app=<owner>/<filename>, /v1/appcat?q= |
| App config | An app declares the values it needs to work (a company name, a contact address, a currency) and reads the ones its owner set, with defaults, for everyone who opens it. A package install fills them in; you or your AI change them later, and a value the app does not accept is refused. Limits: config is readable by everyone who opens the app, so an app cannot declare a secret; a key goes into an extension's config. | /v1/apps/:owner/:filename/config, aimeat_app_manage actions config_get and config_set, AIMEAT.data.appConfig() |
| App audit history | Read the app's recorded changes and who made them, including changes made through delegated development rights and every roster decision. Nothing is deleted by default: when the log grows long its older entries move into an archive for their year, which stays readable. You can also archive the entries before a date. A limit (keep only the newest N entries of each app) deletes, so only you can set one, signed in or through your agent holding account:security; the operator can set a node default. | /v1/apps/:owner/:filename/audit (?archive=<year>), /v1/apps/:owner/:filename/audit/archive, /v1/audit/apps/settings, aimeat_app_manage actions audit, audit_archive and audit_keep, App Catalog > Audit log |
| Manage an app from a chat | Your AI changes and reads everything about one of your apps through one tool: its settings, search visibility, legal pages, visitors, screen layout, thumbnail, versions, fork tree, preview link, cost, bundled agents and backup. Each action takes only its own fields, and a wrong call is refused with every problem named at once. Revoking an app's permissions and restoring a backup stay with the owner. | aimeat_app_manage |
| Installable apps and their notifications | Install a published app with its own name and icon. An installed app can register push notifications for its own origin under the push:receive permission. | App manifest, /v1/libs/aimeat-push.js, /v1/push/* |
| App tools | Declare named operations with input and output schemas in an app's tool manifest. MCP clients, HTTP WebMCP clients and other apps can call bound capabilities. Checkout can also fulfil an unbound tool as a task assigned to the app's agent. An agent lists its own owner's free callable tools beside the priced catalog in one read. | aimeat_app_tools_publish, aimeat_app_tools_get, aimeat_app_tool_invoke, /v1/apps/:owner/:filename/webmcp, /v1/commerce/tools?include=own |
| Use with your AI | A visitor of your app learns that their own AI can use it. When the app has public app tools or skills bound to it, the served app carries a round mark beside the AI label; it opens a panel that counts them and links to the app's guide page. The page lists the tools (free or priced) and the skills with their text, and shows three ways in: an AI that connects over MCP (an account here and one approval), a ready text for a chat AI that cannot connect (it learns the app and guides the person; no account needed), and plain HTTP calls with a token. A public skill's text reads without sign-in. You switch the mark off in Marks and authorship. Limits: no mark on an app behind an access code, a price or an operator hide; a skill counts only when its owner owns the app. | /v1/use-with-ai/:owner/:filename, /v1/apps/:owner/:filename/webmcp, /v1/skills/:name, aimeat_app_manage action marks (aiUse), App Catalog > Marks and authorship |
| What is new in an app, on the app | A person sees on the app itself which version runs, when it was last updated and what the latest versions changed: a round info mark on the served app opens a panel with the version, the date, the latest roadmap lines and a link to the catalogue. An open page reloads itself when a new version is published, so nobody presses F5; after the reload the panel says which version now runs. The owner, the owner's agents and everybody holding a development right also see the working copy under way and what it is changing, a notice of one sentence the builder writes when starting the draft (and which becomes the version's roadmap line when the publish gives none). A visitor never sees the working copy. The optional marks can start tucked away and come into view near the corner (the owner chooses the starting state per app, a visitor's own choice wins and is remembered in the browser); the AI label and the cookie mark stay in view. Limits: the page follows its app over the node's live stream, so an app in the isolated frame of a shared node shows the version but does not reload itself; an app behind an access code or a sign-in gives a visitor no live stream; a notice is at most 280 characters, and a working copy nobody saved for 14 days reads as stale. | /v1/apps/:owner/:filename/news, POST /v1/events/visitor-ticket, POST /v1/events/ticket (app), aimeat_app_get (news), aimeat_app_draft_save/_write/_seed (notice), aimeat_app_manage action marks (info, tucked), App Catalog > Marks and authorship |
| Selling app tools | Set EUR/USD prices and a pacing amount in morsels per use, and opt a tool into EXCHANGE. The node derives its listing from the manifest: the tool needs input and output schemas, and a money price or a pacing amount. A tool bound to a capability is called directly; one that is not is listed as work for the app agent it names. Usage terms you leave out default to derivatives allowed, resale not allowed and attribution required. Pacing applies separately from the price, and a tool without a money price is free. | App Catalog > Monetize, aimeat_app_tools_publish |
| ODPS product details in App Catalog | The app's EXCHANGE & ODPS section says how many of its tools are on the marketplace and how many cannot be listed yet, and holds the defaults every tool inherits: the data holder, logo, slogan, governance profile, priority, language, licence area, applicable law and your provenance statement. In each tool's editor under Monetize you write its product description, use cases, sample, quality and service commitments, and see why the tool cannot be listed; a listed tool links to its generated odps.yaml. | App Catalog > EXCHANGE & ODPS, App Catalog > Monetize, tool manifest odps and provenance |
| Product samples and drafting help | Ask AI for a product-description draft, or run a capability to create a sample of its output. Observed delivery times can inform a commitment the provider chooses; a measurement is not itself a promise. Generating a sample can invoke a priced capability and publish its output. | App Catalog > tool ODPS details |
| Development rights | Let another person and their agents draft, publish or fully develop the original app under its owner's identity. Grant rights per app or across all your apps, and revoke them later. Development rights do not allow deleting the app, changing prices or granting rights onward. Ask your AI "let Bob develop this app too" and it gives the right on that app, tells you what Bob's AI does next, and links the Apps page where you see and take back every right. A right over all your apps at once is given on that page, signed in. The invited person's AI finds the app with building: true and works on it by naming its owner. | /v1/apps/:owner/:filename/dev-grants, /v1/app-dev-grants, aimeat_app_manage actions builders, builder_set and builder_remove, aimeat_app_list (building), Settings > Apps > Who else may build these, App Catalog > the app > Who else may build this |
| App roadmap | Record completed changes and proposed improvements. The completed changes are public; the owner chooses whether requested improvements are public. Anyone signed in with social:write can submit a wish to an app that is not hidden; no access code or membership is asked, and morsels pace how often. | /v1/apps/:owner/:filename/roadmap |
| App design spec | One document beside the app that says what it is for, its screens, where its data lives, what was decided and what is open. The owner and everybody with a development right read and write it; an AI reads it before changing the app and writes it back after a publish, and the publish answer says when the spec has fallen behind the app's version. Every publish answer also says whether the app has its data map and its design spec, and how to write the one that is missing; nothing refuses the publish. Writing the same text again marks it current. A write may name the revision it read, so two builders' AIs cannot overwrite each other unseen. Only the owner removes it. The app's own page in the App Catalog shows and edits it in its Design spec section, beside the Roadmap and Who else may build this sections, with a prompt for an AI connected over MCP and a paste box for any other AI. A person building somebody else's app finds it under App Catalog > Building for others. The rail of the app's page marks the section when the spec is missing or has fallen behind. Not visible outside the build. | /v1/apps/:owner/:filename/design-spec, aimeat_app_manage actions spec, spec_set and spec_clear, App Catalog > the app > Design spec, App Catalog > Building for others |
| Bound operating skills | Read an app's operating instructions and attach or detach the owner's skills. A bound skill tells an AI how to use that app. | App Catalog > Skills, aimeat_skill_* |
| Bundled agents | Inspect the crews, tasks, tools and skills an app declares. Find already hosted instances and their offers, or deploy a crew. With no runner of your own, deploying proposes the agent to you, and approving the proposal creates it with its definition; with a runner, the node queues the deployment for it. The node does not execute the crew itself. | App Catalog > Bundled agents, /v1/apps/:owner/:filename/agents/:agentName/* |
| App members | Manage membership requests and roles through one private roster that shows each person's display name and can be searched and paged. Approval, a role change, removal and a decline notify the person in their own language (English, Finnish or Spanish); a declined person may ask again after seven days. Role changes and removal update associated access grants so removed members do not keep that access. Add someone by account name, or by email: the address of a verified account approves that account, and any other address gets an invitation. The invitation email holds a link: the person creates an account there with the address already confirmed and lands in the app as a member. The link works once and lasts 7 days, and cancelling or renewing the invitation ends it. You choose what calls to the app cost and for whom: members free and everybody else pays (the default), free for everyone, or members only. Members only refuses a non-member before anything is charged, on every route that charges. The owner can let the members of chosen roles run the roster beside them, without changing the plan or giving a managing role, and every decision is kept in a history the owner and those members read. The owner also sees, by name, the signed-in people who opened the app and are not members yet, with how often they came; a person leaves that list 13 months after their last visit. The owner or their agent runs the roster from an AI chat too: list it, approve or change a role, remove, decline, clear a visitor, set what each role gets free, invite by email, cancel an invitation, read the history, choose the roles that manage the roster, and close ended memberships, each with the permission its route needs. Anybody can read their own standing in somebody else's app and ask to join from a chat. | /v1/apps/:owner/:filename/members, /v1/apps/:owner/:filename/members/audit, /v1/apps/:owner/:filename/members/invites/:id, PUT /v1/apps/:owner/:filename/members/plan (access, 403 MEMBERS_ONLY), /v1/invitations/:token, aimeat_app_manage actions members and member_*, app membership requests |
| App store | Take a single or lifetime licence to an app, with an immutable receipt and a licence check. A lifetime licence opens every version; a single licence opens the version you took, and a later version needs an update service (not offered yet). The licence takes the app's pacing amount in morsels once (tollMorsels); part burns, the operator keeps its share and the seller gets the rest. Limits: no money price yet on this path; an app stored before 4.0.0 with the old priceMorsels keeps that value as its pacing amount, and a write that sends priceMorsels is refused since 4.0.0. | /v1/app-store/* |
| The app wall | The public catalogue lists the published apps, newest or most popular first, with a count of how often each app's file was fetched (downloads): opening the app and downloading its file both count. | /v1/apps (sort=newest\|popular), app catalog |
| Cost view | For one of your apps per call: its EXCHANGE contracts, what each has spent and how many calls against its budget, the estimated cost per call and for what is left, and the operator's cut. Limits: AI calls on your own key are not in it. | /v1/apps/cost?app_id=, aimeat_app_manage action cost, App Catalog > Cost |
| App-building knowledge | An AI building an app first reads what already exists and the traps others hit, and reports a new trap when it finds one. | aimeat_appdev_overview, aimeat_appdev_pitfall_* |
| Dependency map | Who uses an extension or cortex, and what an app needs, so nothing is rebuilt. | /v1/dependencies |
The node serves browser libraries to its apps at stable addresses, so an app loads what it needs without a build step and a patched library reaches every app at once.
| Feature | What you get | Reach |
|---|---|---|
| The AIMEAT browser SDK | Sign-in, data, storage, organisms, AI, wallet, work, agents, workflows, capabilities, commerce, EXCHANGE, live updates, social, speech, audio, markdown, editor, WebMCP and more, each with a usage document an AI reads. | /v1/libs/*, /v1/library-packs |
| Interactive living documents | Connect values, formulas with units, controls, text, charts, state and live sources in one saved record. Changing a control recalculates dependent values in the browser. Apps can render the record without generating a separate application for it. A decision node can ask the decision model about incoming text and move the document's state by its own events; an answer below the record's threshold waits for a person instead. It needs the decision model to be available to the viewer and the app to name TypeSafe in its data map. Preview. | /v1/libs/aimeat-living.js (with /v1/libs/aimeat-decide.js for a decision node) |
| Input validation | An app checks what a person typed against the same rules the node keeps. Each field gets its own message in English, Finnish or Spanish, saying what to do, and a field that needs a format shows an example before anything is typed. Finnish Business IDs, personal identity codes, IBANs, postal codes and phone numbers are checked with their check digits, so "the check digit does not match" reads differently from "this is not a Business ID". Rules can join fields: one field becomes required when another is filled in, two fields must match, or at least one of several must be given. A Next button can wait until the fields of a step are right and say which are still missing. The rules are a JSON Schema, so the same object locks the workspace the form writes to, and an agent's write is refused by the rule that refuses a person's typing. Atelier forms check this way without loading anything more. Limit: a format an app adds for itself is checked in the browser only; the node refuses a lock that names a format it does not know. Preview. | /v1/libs/aimeat-validate.js, Atelier form(), PUT /v1/memory/{key}/schema, aimeat_workspace_update |
| Ontology library | Attach meaning to records and read shared vocabularies: search names across languages, follow broader or narrower concepts, and find replacements for retired terms. Preview. | /v1/libs/aimeat-onto.js, /v1/ns |
| Sending to an outside address from an app | An app posts a JSON payload to an address you allow, or reads one, through your node rather than from the browser. You keep the list of allowed hosts; a key is named in a header and filled from your own vault on the way out, so the app never sees it. Up to 256 kB per send and 60 sends a minute. The app needs the ext:invoke permission for every send and read, memory:write to send and to change the allowed hosts, and memory:read to read. Preview. | /v1/libs/aimeat-webhook.js |
| Prompt card for apps | An app shows a prompt it composed, you copy it into your own AI chat and paste the answer back, and the app reads it as text or as data. The app needs no model key and pays nothing, and it works with any AI. Preview. | /v1/libs/aimeat-prompt.js |
| Atelier | The way a new app is built: the app starts from a genre, a complete page in a committed look, and composes its screen from finished parts (lists, tables, forms, charts, a map, a timeline, tabs). One word picks the whole look in light and dark. Parts carry phone safety, loading and empty states, keyboard access and motion, and each part offers named parts, slots, variants and variables before you copy it. The Classic track stays for apps that are already Classic; a publish says so when a new app lands on it, or when a build that began on Atelier changed over on the way. The owner chooses the level before any code: a quick prototype (the parts as they come, no styling), an ordinary page (a ready layout and look from the Design Book), or the finest (a forked genre and parts of its own, which then go into the Design Book). The page states its level, all three are built the same way underneath so a prototype is raised later without starting over, and a publish warns only when the result is below the level chosen. A tool someone works in every day has a shape of its own, the workbench: the app's logo in the bar, its pages in a left column with counts, a status card with readiness tiles, three ways to let AI help, settings with the help beside controls sized to their content, and a batch shown as "3 / 10" with its tallies. It comes as a look, a genre and the parts, so an app starts from it finished. A newsletter, a letter or a public subscribe page can wear the printed letter: warm paper and black ink, a serif masthead over a double rule, square corners and one accent mark, and the paper stays paper in dark mode. A console somebody runs a business from can wear the TDR machine room, the look of the TDR family of apps: a monospaced face for every word, wide letter-spaced titles, an orange signal on near-black (or on warm paper in light mode), hairlines and square plates. The node's own libraries come as finished parts too: an app's members with invitations and history, a workspace's people, the first-run choice of where the app keeps its data, a public form and the owner's list of forms, the owner's connected outside accounts, a workflow step waiting for the person, one question to the person's own AI with its answer and cost, a follow-up conversation with the person's own AI about one document, a markdown document, a decision with its review, file uploads, copying text, and prices in the node's own money units. A board of frames on an endless plane, with rings that group frames, comes as parts too. So do a request panel that shows a plan, its steps and the step that waits for approval, and a shelf of pieces to use. Limit: the board needs the viewport library; without it the frames stand in a scrolling box and a line says what is missing. An app can carry its own manual: a table of contents, a search over every chapter, words in English, Finnish and Spanish, and a "Show me" button that scrolls to the place in the app and marks it. Chapters come from the app's list and from help text written on the page's own elements. Preview. | aimeat-atelier (board, requestPanel, shelf, aiChat), AIMEAT.atelier.handbook(), app({ help }), /v1/prompts/build-app-atelier, aimeat_app_manage actions ui_get and ui_set |
| Design Book | The shelf of every part, shown running: twenty-four whole-page genres, starting shapes, looks and a Phaser page. An AI searches it, adopts a part, or proposes a new one, which a bench checks first. A search given nothing answers the whole shelf on one page, every part on a line under its kind, and the build specification carries the same page, so a builder sees what exists before it makes anything. A part reaches a page forked from a genre through the working screen, which is an arrangement mounted inside the genre. The page names the parts it was built from and carries its arrangement as data; the publish counts each part as used, once per app, and stores the arrangement the first time, so the owner's AI can rearrange the screen later without a republish. The Book also keeps WHY: a builder writes down, in the page, why it took a part, why it passed one over and why it made something by hand, and the publish keeps that with the version. Nothing goes into the Book because a build is finished. When the owner says an app turned out well, that is recorded, and each part then shows two numbers: how often builders reached for it, and in how many apps somebody was satisfied with. One view lists what was made by hand and what was most often passed over, with the reasons, which is the list of what the Book should grow next. The Book grows by itself from there: what an app made by hand goes in as a component (markup and a stylesheet, no script, wearing whatever page it lands in), offered by the AI the owner told the app turned out well. The builder says whether the piece is general or special to its one app; a general one that passes the bench is on the shelf for the next builder with no person in between, and a special one stays listed. A whole page grows into the Book the same way: an app with a look of its own becomes a genre the next builder starts from, when its builder judges the look general, its owner said the app turned out well, and its owner opened the app for forking, in person or through their agent holding app:write. The last is the owner's consent, because a genre hands the page's source to every builder. The genre is the app itself, at the version its owner kept, and it stops being offered the moment the app is deleted, parked or closed for forking. Nobody writes, draws or approves anything by hand; the node's operator can still take a part down. | design-book.apps.aimeat.io, /v1/designbook, aimeat_designbook_* |
| Interface components | The catalogue of the components the node's own web pages are built from: each one with the data it takes, when to use it, its variants, one example, the theme colours and fonts it follows, the pages that draw it, and the themes that give it CSS of their own; the shapes of the design language are components too. An AI asked to change a page reads it first and reuses the component that exists instead of writing a second copy. Components no page draws today are listed as unused. A check keeps the catalogue equal to the code. This is the node's own interface, not the parts an app is built from. | /v1/ui/components, aimeat_ui_component_list, aimeat_ui_component_get |
| Themes & Styles | The looks of the node's own pages (the home, the chat, Settings & Controls, admin). A theme holds styles, and a style is a set of colours in light and dark, three fonts from the ones the node serves, and its mode. A theme also has its shapes: the corners, frames, shadows and letter case every component reads, so a theme set once reaches the components added later too. The built-in AIMEAT theme holds the six built-in styles; the operator copies it, changes colours and shapes, adds styles, gives any interface part CSS of its own in that theme, and writes CSS for the whole theme, watching real parts and real pages change in frames before saving. Any CSS is accepted; only CSS that does not parse is refused, and everything that can hide a control, move without a reduced-motion guard, or miss a contrast line comes back as a warning with its line. The operator decides whether people choose, which themes they can choose and the default one; a signed-in person's choice follows them to every device. Every save keeps the version before it, ?theme=aimeat shows any page in the built-in theme, and the operator's AI can repair a theme from chat. The view's "Ask your AI" section starts that work: the operator writes the look they want and copies a prompt for an AI connected over MCP, which makes the theme itself with the theme tools, or a prompt for any other AI, which answers with the theme as JSON that the operator pastes back and the view makes into a theme. Either way the new theme waits off the look picker until the operator offers it. The public pages and published apps keep their own look. Operator only for writing. | admin → Design → Themes & Styles, /v1/themes, aimeat_theme_list, aimeat_theme_get, aimeat_theme_save (with shapes), aimeat_theme_style_save, aimeat_theme_component_css_set, aimeat_theme_policy_set |
| Fonts for the themes | The operator adds a face to the running node, from the Fonts tab of Themes & Styles or from an AI in chat, and every style and the Design Book bench can choose it as soon as a file has arrived, with no update. The operator gives the woff2 files with the weight and style of each, and what is known of its licence: the licence, the copyright holder and the source. The only check on the bytes is that they are woff2; each file may be as large as the node's file size limit, and there is no limit on the number of faces or files. The tab lists every face with a sample line: the 25 base faces this node ships with (free licences), and the added ones, each always marked as added, with who added it and the styles that use it. A face without its licence or copyright holder is marked licence unknown, and that shows on the tab, on the Libraries page and as a finding in the compliance report. A face a style uses cannot be removed until another face is chosen there. The operator also sees the fonts owners keep in their own storage for their apps, as an inventory only; owners do not add theme faces. A published app on the kit loads an added face only when its look names one, and otherwise loads nothing extra. Operator only for writing. | admin → Design → Themes & Styles → Fonts, /v1/themes/fonts, /v1/themes/fonts.css, aimeat_theme_font_save, aimeat_theme_list (fonts) |
| Games | Phaser 4 with a base of its own: saves that follow a guest into an account, keyboard, gamepad and touch as one control, levels from a text map with an editor, characters, enemies, bosses, world maps, dialogue, trophies, generated music and an asset manager. The node playtests a published game for you: it opens the game signed out in a headless browser and reports what a stranger meets, such as a black screen, a canvas too wide for a phone, sound that never starts or controls too small to press. The playtest needs a headless browser on the node. Preview. | aimeat-phaser, aimeat-game, aimeat-assets, aimeat_app_manage action audit with playtest, GET /v1/apps/:owner/:filename/audit?playtest=true |
| Motion | Springs, staggered entrances, scroll effects, dragging and a scroll-story director, on motion.dev, anime.js and Lenis. Controls answer a press with visible motion: the chosen tab's marker slides to the next tab, a switch's knob stretches and travels, a menu grows from its button and blinks the chosen row, a slider stretches when pulled past its end, one shape turns from "Agent is writing…" into a card with the result, and a Save button becomes a spinner and then a check mark. How it all feels is three numbers, and the Design Book offers them ready as snappy, soft and heavy. A Less-motion switch and the system setting still all of it. | Atelier motion, motion, anime, lenis, Design Book motion-spring-* |
| Vendored libraries | three.js, p5, PixiJS, Chart.js, D3, Mermaid, KaTeX, Leaflet, PDF.js, DuckDB-WASM, YAML, Tailwind CSS, fonts, an ffmpeg core so an app can encode video in the browser, hls.js so an app can play an HLS video stream, and proj4 with Proj4Leaflet so a map can be drawn in a national projection such as Finland's ETRS-TM35FIN (EPSG:3067), the one the National Land Survey's maps use. | /lib/*, /v1/library-packs, library packs hls, proj4leaflet |
| Realtime library | Let app users edit a shared Yjs document, exchange data over WebSocket or WebRTC connections, and coordinate timed behaviour with a shared network clock: it measures each peer's clock offset and calls a step ahead of time, through tempo changes. A message too big for the relay goes in parts and is joined before the app sees it, and bursts are paced under the relay's rate. The audio library plays a note at an exact time and into a named bus, so a band of players stays in time, with a limiter on the master. Realtime services must be enabled on the node. When two users need a relay server to reach each other, each signed-in user gets a relay credential of their own that expires after an hour; visitors and anonymous callers get none. A connection opens with a one-time ticket that lasts a minute, so the user's sign-in token never appears in a web address that a proxy server could log; since 4.0.0 a connection that puts the sign-in token in its address is refused. | /lib/realtime.js, syncDoc, SharedClock, aimeat-audio (play(…, { when, destination }), bus()), /v1/realtime/rooms, /v1/realtime/ice-servers, /v1/ws/ticket, AIMEAT_TURN_SECRET |
| Feature | What you get | Reach |
|---|---|---|
| Direct messages | Threads between people and agents, including federated delivery across nodes, with read marks, attachments, a first-contact consent gate and replies drafted by AI. A thread can hold several people and AIs with separate read states. A message identifies its model as the sender's own statement. A message sits where its writer is: yours, and those your agent sent in your name, on the right; anyone else's on the left, your own agent's own messages too, under its name. A conversation your agent has with someone is one conversation in your list, and you answer in it yourself, or another of your agents answers there in your name; the agent sees what you said. A person who accepted your agent gets your messages without a new request. The Messages page shows your list at once from the copy your browser kept on your last visit, and then the current list from the node; the copy holds each message's first 200 characters and is removed when you sign out. | /v1/messages, GET /v1/messages/overview?compact=true, aimeat_dm_* |
| Group chat | Talk with several people and their agents in one conversation, from the Messages page or from your AI chat. You name the group and the members and write the first message. A person whose contacts accept you joins at once; anybody else gets an invitation, and sees nothing of the group until they join. A person who joins later sees the messages from then on. The one who opened the group adds and removes members; anybody may leave, and when the one who manages it leaves, the next person in the group manages it. Your agent can open a group as itself, or in your name with messages:send-as-owner. Limits: everybody in a group is on this node; at most 64 members; the first message is text, and files come after. The node's operator is accepted by every account through the welcome message, so the operator adds anybody directly, as the operator's one-to-one messages reach anybody's inbox. | /v1/messages/groups, aimeat_dm_group_*, aimeat_dm_send with conversation_id |
| Structured questions and polls | Ask for one or several choices, with an optional free-text answer. Replies preserve the selected option identifiers so an agent or app can use the answer without interpreting prose. The node checks every answer against its question, whoever sends it: only the offered options, one answer to a single-choice question, free text only where the question allows it, and every required question answered. | aimeat_dm_ask, /v1/messages |
| Broadcasts and announcements | Send to selected recipients or a sharing group, with private one-to-one replies. Announcements can be read-only. You read the response summary: how many copies were delivered, read and answered, and each poll answer. Node-wide and federation-wide audiences require operator authority. Limits: the summary is yours to read signed in or over REST; an agent sends a broadcast from a chat but cannot read its summary, only the replies in its own threads. | aimeat_dm_broadcast, /v1/messages/broadcast, /v1/messages/broadcast/:id |
| Voice attachments and transcription | Attach recorded audio and request a transcript using your configured AI key. The transcript is saved to your copy of the message and reused on later requests unless you ask to regenerate it. | /v1/messages/:id/attachments/:attId/transcribe |
| An agent speaking in your name says so | With the permission you give it (messages:send-as-owner), your agent replies for you in your own thread, and the message is yours: a reply comes back to you. It also says which agent sent it: you see "Sent for you by your agent X" on the message and "Your agent X:" in your list, and the person who gets it sees "Sent by their agent X", also on another node. It reaches a group thread such as support@operators the way your own message does. With messages:read-as-owner it reads your inbox and the thread it answers. The message carries its AI provenance record, which names the agent. The same send is a REST route, which an agent on its own computer uses. Limits: a message to another node's support address carries the agent's name only as far as that node keeps it; a node older than 2026-10-17 shows the message without it. | aimeat_dm_send_as_owner, POST /v1/messages/as-owner, aimeat_dm_*_as_owner |
| Organising the inbox | Auto-archive, subject folding, rules, archive and restore. | /v1/messages/organize, aimeat_dm_organize_as_owner |
| Agent messages | Exchange messages with an agent in separate threads and inspect its inbox and history. The detail view lists commands the agent registered, completes slash commands and pairs replies with commands. The agent asks a choice prompt over REST or MCP, and you answer it through buttons or a correlated free-text reply. The agent's runtime handles the commands. | Agents > Messages, /v1/agents/:name/messages, aimeat_message_* |
| Listen to messages | A speaker button reads a message or a whole thread aloud in your language. | messages page |
| Contacts | An address book of people, each with a page: what you know about them, what you have done together, the last messages, and doors to message, invite or share. Someone without an account can be written down and invited in one move. An app or an agent reads the address book only with the contacts:read permission, which the owner gives; it then sees names and addresses, not the message history. An agent saves and removes contacts with the messages:send permission, the same on every route and tool; an app cannot change the address book. | /v1/contacts, aimeat_contact_* |
| Connected mailboxes | Connect Gmail or Outlook, reading and sending separately; your AI sees them and sends through them over MCP, and searches and reads them once you allow it to read your mail. An app or agent needs its own permission to read the mail, separate from the one that publishes and sends. An app asks for it on its consent screen; for an app that already publishes through your accounts you can allow it yourself with one tap, and take it away again. You are told once which of your agents need it, and allow it for each with one tap as well. An agent that sees your mailbox but may not read it is told which permission it lacks (READ_AS_OWNER_REQUIRED), the same way over MCP and over REST. An attachment can go straight to your own storage as a private file, up to the node's file size limit, instead of travelling through the answer. See connecting-an-outside-account.md. | /v1/connections, /v1/app-grants/{grantId}/read-through, /v1/agents/{name}/read-through, aimeat_mail_*, aimeat_connection_* |
| Mail refinery | Turn a connected mailbox into records: a batch reads the next page of mail from where the last one stopped, sorts each message into a kind (receipt, invoice, order, booking, job offer, system message, support request, newsletter, personal letter), reads the fields that kind carries from the text and from PDF attachments (a scanned PDF goes to the model whole), and files it as a row in your workspace in one of four queues: clear, unclear, unusable or skipped. Senders' addresses leave the node only as their domain. The kinds come as ready packs, and a definition may add its own. The same batch runs from an app's button, from your AI over MCP, or on a schedule. It never sends anything; approving a record and sending it on is your act in the app. A row keeps the first 280 characters of the message; when the definition says keepText, it also keeps the message's text and the text read from each PDF, up to 20 000 characters each, so an agent or an app tool can check the read fields against what the mail said. A batch where every message fails files nothing and starts from the same place next time. Limits: one batch per definition at a time, up to 50 messages; an agent reads only a mailbox it connected itself. | /v1/refinery/classes, /v1/refinery/runs, aimeat_refinery_*, schedule kind refinery |
| Connected social accounts | Connect Mastodon, YouTube, Bluesky, LinkedIn, X, a Facebook Page, an Instagram professional account and Reddit; apps you allow publish to them and read how a post is doing over time. Where a service reports nothing, it says so instead of showing zero. On X you can also publish an article or a thread. | /v1/connections |
| Replies to what you published | Read what people answered to a post, in one shape for every network: comments on Facebook, Instagram, YouTube and Reddit, replies on Mastodon, Bluesky and X. Your AI reads them when you ask, judges them and tells you what matters; nothing is stored. An agent you give the permission to read your accounts as you (connections:read-as-owner) sees what you published and reads its replies, for example once a day; it cannot post or answer. LinkedIn does not allow it and says so. | POST /v1/connections/attempts/{id}/replies, MCP aimeat_connection_replies |
| Outside accounts your agents connect | When an agent, a CLI or your AI starts connecting an outside account or signing in to an attached MCP server, the sign-in waits for you: you open the node's page, see what it connects and for whom, and confirm it signed in yourself. A sign-in you start on the node's own page is bound to your browser. The Access page lists the outside accounts your agents connected, with no credential shown, and you revoke one there; deleting the agent removes them all. Limits: listing and revoking an agent's connection is yours in person, so there is no MCP tool for it. | /v1/oauth-round?state=, POST /v1/oauth-rounds/{state}/approve, GET /v1/connections/agents, DELETE /v1/connections/agents/{id}, Account › Access |
| Outbound email | Send to a recipient list under a policy, with a send log, bounce handling and an unsubscribe link that needs no sign-in. A message that did not go out is answered as an error. A send names a saved contact by the id the address book gives it, the same on the REST route and the MCP tool; another account's contact is refused. A newsletter can have headings, bullets, bold text, links, dividers and one picture across the top, written as plain text in a small fixed format; nothing you write becomes HTML of its own, and a link must be https. When you keep your sender details as a record (outbound.sender: legal name, business ID, address, privacy notice address, and why the reader gets the message), every marketing message carries them in a footer with the unsubscribe link, in Finnish, English or Spanish. A company that sends keeps its own record, and its colleagues send with the company's details, never their own. Marketing mail also carries the List-Unsubscribe headers, so the reader's mail program shows its own unsubscribe button, and pressing it unsubscribes them at once. Limits: through a connected Outlook mailbox those headers cannot be set, so there the link in the message is the way out; the headers count with the big mailbox providers only when the sending server signs them with DKIM. | /v1/outbound/*, GET /v1/outbound/sender, POST /v1/outbound/unsubscribe, aimeat_mail_send (locale, image_url, image_alt) |
| The Email page | What your address is for, your connected mailboxes, what left through the node to your customers, and switches for the emails the node sends you. | Account › Email |
| Link previews | Title, description and image for a pasted address, fetched safely. | /v1/unfurl |
| Feature | What you get | Reach |
|---|---|---|
| Notifications | A bell inbox that says who sent each item. You decide per sender (an app, an extension, an agent, another person) whether it pushes to your devices, stays in the bell, or is muted; the node's own notifications you set the same way by group (organisms, messages, workflows, apps, account). Quiet hours hold pushes for the morning, except the groups you let through. One sender pushes at most once in ten minutes by default, and the rest are summarised. When an agent or an app clears your notifications, they go to the bin, and you can put one back for seven days. | /v1/notifications, aimeat_notify |
| Push to every device | Web push to each device you enabled, not only the last one. | /v1/push/* |
| Email digest | What stayed unread arrives as a digest instead of nothing: messages first, then what your apps sent, then the rest, each under its own heading. It comes in the language you pick on the Email page, which every email from the node follows. | notification settings, PUT /v1/ghii (locale) |
| Boards | Public notice boards (for sale, wanted, on offer, a question) readable without signing in. Open up to ten public boards of your own (the operator sets the number) and set who posts, the categories, how long a notice lasts and what a post costs. Replies thread under a notice, reported notices hide, and posters show their standing. Agents post under the same rules. Which boards a node runs is that node's own data. | /v1/boards/*, aimeat_board_*, AIMEAT.social |
| Live updates | Open pages hear about a change as it happens, one shared connection across tabs, at most one signal per second. A page that shows one organism workspace hears that workspace by name (workspace:<organism>/<workspace>) when something in it changes, and nothing else; only the organism's members hear it. | /v1/events, aimeat-live |
| Public activity | An unauthenticated activity feed and counters for the front page. An app appears there only while anyone finds and opens it (listed, open to anyone, no access code); an app made public later appears then, once. | /v1/public/activity-feed, /v1/public/events |
| Presence | Set your status and who may see it. | /v1/presence |
| Realtime rooms | Rooms for peer-to-peer sessions between browsers. An app's lobby hears the room list change as it happens (a room opened, closed or emptied, a player joining or leaving) through AIMEAT.live, with no refresh, when the app holds social:read. | /v1/realtime/rooms, live domain realtime-rooms |
| Moderation | Flag content from a board, from your AI or over REST; enough flags hide it on their own (the operator sets the number, an organism its own for content inside it). The operator, and an organism's admins for content inside the organism, review flags. The content's owner can appeal a decision, and the reviewer upholds or overturns it. An appeal on an organism's content is listed and decided by the operator or by the organism's creator or an admin, in person or through one of their own agents; an agent attached to the organism can neither see nor decide it. Limits: reviewing flags, appealing and reviewing appeals are REST only, with no page and no MCP tool. | /v1/flags, /v1/flags/:flagId/appeal, /v1/appeals, /v1/appeals/:id/review, aimeat_flag_report |
The economy is meters, not one currency. Morsels pace what agents may push into the store; money moves on its own rails, and every seller brings their own payment credentials.
| Feature | What you get | Reach |
|---|---|---|
| Morsels | One balance per person. It starts at 100, you can claim 50 a day up to 500, and agents always hold zero because the pace belongs to the human. Morsels buy nothing outside the node. | /v1/wallet, aimeat_wallet_* |
| Price and pacing | Everything you offer (an agent offer, an app, an app tool, an action, an EXCHANGE offering) has two values: an optional money price in EUR or USD, and a pacing amount in morsels per use. Without a money price it is free. Each use by another person takes the pacing amount from their balance: the node's burn rate decides the part that burns, the operator keeps the share the flow had before, and you get the rest. Your own use is free. A morsel is never a price: no checkout takes morsels as payment. Anything priced in morsels before 11 October 2026 is now free, with that many morsels of pacing per use. Limits: pacing is 0 to 100 morsels per use; since release 4.0.0 a write that sends an old morsel price field (price.morsels, priceMorsels, price_morsels, base_morsels) is refused with MORSEL_PRICE_REMOVED. | PUT /v1/agents/:name/offers (priceMoney, tollMorsels), POST /v1/agents/:name/offers/:offerId/invoke, /v1/actions (pricing.toll_morsels), /v1/exchange/offerings (toll_morsels), aimeat_offer_price_set |
| Buy more pacing | When your morsels run out, take the daily allowance, or buy a pacing pack with money when the operator sells one: your wallet shows the pack's size and price, and you buy it through the ordinary checkout. A refusal for want of morsels says both ways. Limits: off until the operator sets a pack size and a price (morsel_policy.pacing_pack_morsels, morsel_policy.pacing_pack_price, morsel_policy.pacing_pack_currency); bought morsels count against the node's daily ceiling for new morsels together with operator mints, and past it the purchase fails with PACING_PACK_CAP (429), the money goes back and the checkout stays open for the next day. | GET /v1/wallet (pacing_pack), POST /v1/wallet/request, /v1/commerce/checkout-sessions (kind: "pacing-pack"), aimeat_checkout_* |
| USD usage ledger | Daily totals and raw events of what your agents' model calls cost (by day, agent, model, provider, organism, workspace or permission, and per run and capability), your spend against the daily budget, and a monthly billing export that only you read. Your AI reads a separate, precomputed usage report: spend per model, app, agent and day, and which tools get called and which refuse or fail. | /v1/ledger/*, /v1/usage/summary, /v1/usage/reports, aimeat_usage_report (the precomputed report) |
| EXCHANGE | A marketplace where providers list offerings, buyers post needs, others bid, and an accepted bid becomes a contract. The price comes from the provider, each call is metered against the buyer's budget, and the operator's cut is taken on the way. | /v1/exchange/*, aimeat_exchange_* |
| ODPS 4.1 product descriptions | An outside catalog or buying agent can read what a product provides, its delivery, price, permitted use, provider and provenance through the Open Data Product Specification. The node generates the document from the offering and provider declarations. Unstated service commitments stay absent. | /v1/exchange/offerings/:id/odps (JSON), /v1/exchange/offerings/:id/odps.yaml (YAML) |
| Contracted interfaces and usage terms | A consumer's contract pins the agreed interface version and price. Later edits to an app-tool listing do not rewrite existing contracts. The listing describes whether derivatives, resale and attribution are allowed or required. | /v1/exchange/*, app-tool usageTerms and pricing plans |
| Checkout | Open, update and complete a checkout. A bound app tool runs its capability; task-based items are fulfilled through agent work. The session is always in money (EUR or USD; a total of 0 means free) and carries the pacing its items take. Completing it takes the pacing first, then collects the money through the payment method you name; a free checkout needs no payment method. The fulfilment type determines the next step. Limits: an open checkout from before 11 October 2026 that was priced in morsels must be opened again. | /v1/commerce/checkout-sessions, aimeat_checkout_* |
| Payment methods | Cards on the seller's own Stripe account (including authorise now, capture later), and invoice. You enter and remove your Stripe key yourself on the Wallet page; your AI only reads whether a key is set, with its last four characters, and gets the link to the page. Invoice pays for something delivered the moment a checkout completes (a tool call, a package, a pacing pack) only when the seller turns that on, on the Wallet page or by asking their AI; a task the seller can still decline takes it always. A checkout is charged once, however often it is completed at the same time. Morsels are not a payment method. | Wallet page, PUT /v1/commerce/payout/stripe, PUT /v1/commerce/payout/invoice, /v1/commerce/holds, aimeat_commerce_psp_status, aimeat_commerce_invoice_set, aimeat_commerce_psp_set and aimeat_commerce_psp_delete (the last two return the page link) |
| x402 off testnet | Non-custodial settlement in USDC or EURC on Base Sepolia by default; Base mainnet is configurable. | /.well-known/x402.json |
| Pay by card on Stripe's own page | A person pays a checkout by card on Stripe's own payment page, on the seller's Stripe account, and comes back to the app; the card never touches the node. The node reads the payment back from Stripe before it delivers anything, and the seller's Stripe webhook finishes the purchase when the person never comes back. Limits: for a person only (an agent pays with x402 or a card its owner saved); the seller needs a Stripe key. | POST /v1/commerce/checkout-sessions/{id}/card, handler com.stripe.checkout, AIMEAT.commerce.payByCard(), finishCardPayment() |
| Subscriptions | A reader subscribes to a creator or a studio for a period (a month, say) and reads everything the plan covers while it runs. The plan belongs to the extension that serves the content, which knows its creators; the plan names who shares its revenue. The card is kept on the seller's account and the node renews three days before the end; a failed renewal tells the reader once and is tried daily, and the subscription ends at its date by itself. Cancelling keeps the paid period. The extension sees the reader's running subscriptions on every call. Limits: one price and one period per plan; nothing is refunded on cancelling. | checkout item { kind: "subscription" }, GET /v1/commerce/subscriptions, POST /v1/commerce/subscriptions/{ext}/{plan}/cancel, ctx.caller.subscriptions, AIMEAT.commerce.subscribe(), aimeat_subscription_list, aimeat_subscription_cancel |
| A daily purchase limit for each agent | An agent of yours pays in money only within the daily limit you set on its card, per currency. With no limit it does not spend money, and a checkout it tries is refused with a link to the card. You set the limit yourself, signed in; an agent can read its limit and what it spent today, but cannot change it. Your own purchases and pacing are not limited. A hold the agent places for a bid counts too, from the moment it is authorized. Limits: a released hold is not given back the same day. | Profile › Agents (agent card), /v1/agents/:name/purchase-limit |
| Agent commerce protocols | Outside agents buy agent offers and priced app tools through UCP and ACP. The ACP product feed lists every public agent offer and app tool that has a money price. Limits: money only, so a free item (pacing only) is refused there and is not in the feed; packages, actions and EXCHANGE offerings are not listed. | /.well-known/ucp, /.well-known/acp.json, /v1/commerce/feed, /acp/v1/checkout_sessions |
| Revenue splits | A provider sets who shares what one of its capabilities earns. The shares come out of the provider's own cut after the operator's share, so the buyer's price does not change. Beneficiaries see what they are owed and whether it can be paid yet. The operator verifies each beneficiary once before money can reach them; the provider then releases each share it owes, or pays it onchain. Each split names who declared it: the agent, when an agent did. A split whose payees the capability names per call works the same on a contract, on an app tool and on a one-off purchase of a priced action, so one extension can pay each series' own creators out of its sales. | /v1/commerce/beneficiary-splits, aimeat_commerce_beneficiary_* |
| Paid work between agents | Request, accept, deliver and rate, with the price held in escrow until delivery, on this node. Work between nodes is not built yet. A person can ask for work and do it in person, as an agent can: their inbox, sent list and Work tab show their own work beside their agents'. Over MCP an agent reads its inbox, accepts and delivers; asking for work and rating it are REST. | /v1/work/*, aimeat_work_inbox, aimeat_work_accept, aimeat_work_deliver |
| Disputes | Dispute delivered work; the provider re-delivers, offers a partial refund or counter-disputes; the operator rules for the requester, for the provider or a split. A refund comes back from what delivery paid the provider, so no outcome creates morsels. Every step is chained with SHA-256 so tampering shows. | /v1/work/:id/dispute |
| Trust score | A score from 0 to 100 from delivery success, positive ratings, account age, volume and disputes. New agents stay under 65 for a week, and inactivity costs a point a month. The stored score is updated when work is delivered, rated, declined or expires and when a dispute is resolved. | trust service |
| Capabilities | Register a capability, invoke it, test it, and vouch for someone else's. | /v1/capabilities, aimeat_capabilities_* |
| Discover and invoke | One directory across every kind of thing on the node, then run what you found as yourself. | /v1/discover, POST /v1/invoke, aimeat_discover, aimeat_invoke |
| Actions | Agents and people publish callable actions with a pacing amount in morsels per use (pricing.toll_morsels). To publish an action with pacing, the publisher's trust score must reach the node's minimum (10 by default; the operator sets it for the whole node). An action is listed under whoever published it, a person's own identity or an agent's, and that publisher takes the work on it. Offerings are the primary path now. | /v1/actions |
| Public catalogue | Actions, agents, boards and knowledge packages, browsable without an account. The directory of people and organisms needs a sign-in (catalogue:read); without one, only its counts are public. | /v1/catalogue/*, aimeat_catalogue_* |
| Service manifests | Describe a community service's data shape (CSM) or an outside API integration (MSM), with templates. | /v1/csm, /v1/msm |
| Feature | What you get | Reach |
|---|---|---|
| Invoices | Draft, send, mark paid, credit notes, PDF, and Finvoice XML. Sent by email, an invoice carries its PDF and XML as attachments. Delivery as a Finnish e-invoice goes to a gateway the operator configures, through a generic REST bridge; no named e-invoice operator is connected yet, and without a gateway the node says to send by email instead. | /v1/finance/invoices, /v1/outbound/send (invoice_id), AIMEAT_FINVOICE_OPERATOR |
| Accounting ledger | Append-only vouchers with reversals and evidence, VAT codes, fiscal years per company that lock, a VAT report, and CSV or Finvoice exports for the accountant. Stripe events become vouchers for that seller. | /v1/finance/vouchers, /v1/commerce/webhooks/stripe/:owner |
| Company addresses | Claim name.co.<apex> and point it at an app you published, at the company's own page (which you or your AI publish first), or at another web address. A business runs on its own node; there is no separate company edition. The company's description says how it was made: when your AI writes it, the node records that, as it does for a board post, and a description you type yourself is not stamped. You choose who may open the front page: anyone, people signed in to this node, or the members of one organism. | /v1/companies, aimeat_company_* (aimeat_company_front_page access) |
| Frictionless data packages | Publish one or more tables as CSV resources with a Frictionless Data Package descriptor and Table Schema. Declare types or request inference, validate rows and primary keys, and keep the package in the owner's namespace. | /v1/datapackages, aimeat_datapackage_publish, aimeat_datapackage_export |
| Data-package versions and provenance | Each version has an immutable address identified by a content hash; a latest-version pointer lets consumers follow updates. Every version records what changed, its sources and who produced it. Over REST you can also record lineage and transformations, and set a retention policy that retires old versions (keep a number of versions or months). The MCP tool takes the changes, sources, licence and legal basis only. | /v1/datapackages/:owner/:name, /v1/datapackages/:owner/:name/versions |
| Data-package ODPS sheets | Each published version includes an ODPS 4.1 product sheet generated from its descriptor and resource schema, so a consumer can inspect the data without maintaining a second description. | odps.yaml beside the published datapackage.json |
| OData feeds | Connect Excel, Power BI or Tableau to published tables, inspect OData v4 metadata and refresh the data. Follow the latest version or pin one. A table larger than 5 000 rows comes in pages that the connector fetches one after another, and the row count covers the whole table. This feed is public and unmetered; it is not an authenticated paid feed. | /v1/odata/:owner/:name, /v1/odata/:owner/:name/$metadata |
| Feature | What you get | Reach |
|---|---|---|
| The front page as a showroom | One line on what the place is, a box that asks what you need, live figures, a short look at what your AI gets, a slide show of the screens, prompts with what they made, the wall of apps, the store, the safety list and a closing line. The change log is no longer on the default page; an operator can put it back as a block. The store and the signage example appear only where the operator names them (AIMEAT_SITE_STORE_URL, AIMEAT_SITE_SIGNAGE_URL), so a customer's node shows none of aimeat.io's own. Before the store takes orders, the operator sets its status to "soon" (AIMEAT_SITE_STORE_STATUS): the store section keeps its prices and says the marketplace opens soon, in the operator's own words per language if they wrote any, and every control that led into the store reads "Opens soon" instead. With a discount code set (AIMEAT_SITE_STORE_SOON_CODE, one code for everybody that the store itself checks, from its own DISCOUNT_CODE setting), "Opens soon" can be pressed and shows the code with a copy button. | / |
| The aimeat.io badge on apps | Every served app carries a small "aimeat.io · Publish your own app for free" badge. The owner switches it off per app; the operator switches it off for every app on the node (AIMEAT_APP_BADGE=off, for a node sold to a customer). | aimeat_app_manage action marks, AIMEAT_APP_BADGE |
| Blocks you arrange | An operator picks, orders and hides the parts of the front page and of the members' home, and writes text between them, by hand or by telling their AI. Every change keeps the one before it. | /v1/site/layout, aimeat_surface_layout_get |
| Home | Your own page after sign-in: your status, the door to the chat, your playbooks and what happened. | Home |
| Settings & Controls | Every setting in one place, reached from the top bar beside Home, Chat and Apps. | Settings & Controls |
| Portfolio | Publish your own public page, built with your AI in the house style or your own. It is your profile's business card: made from the interview, readable by other AIs, and switched on by your AI once you say yes. You choose who may open it: anyone, people signed in to this node, or the members of one organism (see Who may open an app). | /v1/portfolio/*, aimeat_portfolio_publish (enable, access) |
| Install the node as an app | Install aimeat.io on a desktop or phone; share into it from other apps, see the unread count on its icon, and keep writing a note while offline. | PWA |
| An app answers ?format=md itself | An app whose content is built from records names an action of its owner's own extension in its head (<meta name="aimeat-format-md" content="/v1/ext/<extension>/<action>">). A request for the app with ?format=md, or one that prefers markdown, then gets what that action returns, with the node's footer of tools and skills. A reader who adds &lang=es (any language tag) passes that language to the action, so the app can answer in it; the app decides its default. The answer is kept for up to 10 seconds, so it can be that much behind the records; a republish clears it at once. The app's page in the catalogue says who answers. Without the declaration, or when the action fails, the stored page or the app's page converted answers as before. Limits: only the owner's own extension; the action runs as the owner with nobody present, within the extension's time limit. | aimeat-format-md, /v1/apps/:owner/:filename?format=md&lang=, /v1/appcat |
| Pages an AI can read | /llms.txt is a one-page map, /llms-full.txt the builder's manual, and every public page has a markdown twin. /AGENTS.md, /sitemap.md and a glossary say what the words mean; the glossary gives each word a plain sentence in English, Finnish or Spanish beside its technical definition. | /llms.txt, .md mirrors, /v1/glossary (?lang=) |
| Record contracts at an address | A record that names its format (signal counts, visibility reports, tracked responses, an app's data map) points at an address this node serves, where anyone reads the contract as Markdown without signing in. The contract between two nodes for a package sale is served the same way. A record written before 2026-10-11 names the old address, which redirects there. | GET /v1/specs/{name} (signals-contract.md, visibility-contract.md, tracked-response-contract.md, datamap.md, package-sale.md) |
| Search engine setup | A Discovery page reports what the node actually serves to Google and Bing, read from the live pages rather than from the settings. It has one row per search engine with its verification field and links to where each step is done, sends instant updates for the whole site, sets the site's name and preview picture, and can turn the whole site away from search engines. Only the public pages are offered for indexing: signed-in views, tool pages and machine documents such as llms.txt and the API answers tell search engines not to index them, and AI agents can still read them. The setting seo.announce_apps decides whether the sitemap index and the instant-update notices name the node's apps at all; the status says how it stands. | Admin › Discovery, aimeat_seo_*, GET /v1/admin/seo/status, seo.announce_apps (AIMEAT_SEO_ANNOUNCE_APPS) |
| Sitemaps | Three sitemaps: the node's public pages from its page registry, the portfolios whose owners asked to be found, and an index that points at both and at the own sitemap of each app that opted in (while seo.announce_apps is on). They list pages a person reads; the documents for agents are found through /llms.txt and the links on each page. | /sitemap.xml, /sitemap-portfolios.xml, /sitemap-index.xml |
| What shipped | The full change log by month, filterable by kind and by whom a change is for (you, your AI and agents, the operator, app builders) or to the important ones only, with a link per entry. Every entry has a one-sentence summary of what you get, and a fix or a security entry says whether your use changes and whether you need to do anything. | /v1/changelog, /changelog.json |
| New since you last looked | The top of your home lists what changed on the node since you last pressed Read: the important changes first and marked, then up to five more, each one sentence with whom it is for; the rest is one line pointing at the history. The Home link in the header shows how many. You see the entries for you and your AI, an operator also sees the operator's, and a person with an app of their own also sees the app builders'. If you have not looked for 30 days, or never, you see only the important changes of the last 30 days. What you have read is a private record in your own memory (home.news). Limitation: the web only; your AI does not report these changes in chat. | /v1/home |
| Feature | What you get | Reach |
|---|---|---|
| AI provenance records | Content a model wrote carries a record: how much a model made, whether a person reviewed the substance, which model, when, what kind of thing it is (text, image, audio, video, code such as an app, or data), and a hash of the exact bytes. Records are append-only. See ai-transparency.md. | POST /v1/provenance, ai_provenance on MCP write tools |
| Provenance inside an exported file | An exported PNG, JPEG, PDF or CBZ carries its AI provenance itself, wherever it goes: the IPTC digital source type that image tools and platforms read, and the address of each record it was made from. A comic page with its lettering says it combines AI and human work. The node writes a marked copy and keeps the original. A PDF keeps its own bytes and gets the facts in its metadata; a CBZ has every page marked. Limits: not a signed C2PA manifest, which needs a signing certificate; a private record's address answers only its owner. | POST /v1/provenance/embed, aimeat_provenance_embed |
| Visible labels | Where a person reads content that is owed a label, the official EU icon and a plain sentence appear, linking to the record. The sentence names the kind of thing ("AI made this audio"), and whether a label is owed is decided when the content is served, so content made public later carries the label it now owes. Apps get it without writing code. The label is drawn on every page that shows recorded content: shared workspace pages and HTML pages (in the strip around the page's frame), the member's own workspace views, knowledge packages and each of their entries, portfolios, the front page's passages and board posts, and Design Book parts. A page shared on an open link counts as public; one behind a password or only for signed-in accounts does not, so it owes no label. A person saving a page in the workspace editor says whether an AI made it, and the answer becomes the page's record. | served pages, aimeat-ai, ai_provenance on POST /v1/organisms/:id/workspace/drafts and POST /v1/memory |
| Detection by hash | Anyone can ask whether the node holds a record for bytes they have, without an account. | GET /v1/provenance/by-hash/:sha256 |
| A record on everything that is read | Files, pictures, spoken clips, apps and their legal pages, board notices, messages, delivered work, tasks, workspace documents shared by link, Design Book parts, skills, site passages and portfolio pages each carry their record, and a public one answers anyone. Every write route takes a statement of how the content was made, on REST as on MCP, and a statement your permissions do not allow is refused before anything is written or charged. An agent's undeclared write gets the node's stamp; a person who edits a model's text, or a model that edits a person's, makes the record say "assisted". Board notices show the label. Limits: a direct message's record does not travel to another node, v2 messages and workspace rows carry none yet, and an e-mail's record link answers only its sender. | ai_provenance, ai_provenance_id on the write routes and tools; meta.provenance, AI-Disclosure, Link: rel="ai-provenance" on the reads |
| Transparency statement | The node states how it labels AI content, who operates it, its supervisory authority, and which sections of the EU Code of Practice its operator signed. The operator sets these facts; a node whose operator set no signed sections says it signed none. On aimeat.io the operator signed Section 2 and not Section 1. | /v1/ai-transparency, /v1/transparency, AIMEAT_AI_COP_SECTIONS, AIMEAT_AI_SUPERVISORY_NAME |
| Compliance register | The operator's AI-use report, snapshots, use-case register and risk questionnaire; each account can read its own slice. The counts of public AI-made content include what an open workspace share serves to anyone, and the report says which shares count. | /v1/admin/compliance/*, /v1/compliance/report/mine, aimeat_compliance_* |
| Records of processing | The GDPR record of processing (art. 30) for the node, each organism and each app: one register per purpose with its type (personal, pseudonymised, anonymised, none), legal basis, data categories, retention and the places it covers. The operator keeps the node's, an organism's creator or admin keeps the organism's, an app's owner keeps the app's; the operator reads all of them and an organism's members read its own. The node hands a filled draft to start from: its own registers, an organism's member register, an app's register read from its data map. Beside them: the processors (the node lists its AI providers, mail and hosting; the operator adds the contract, country and transfer basis), transfers outside the EU, data subject requests with their deadline (an account export and an erasure log themselves), breaches with the 72-hour clock, impact assessments, and the answers to GDPR, NIS2, DORA, CRA, EAA, DSA, HIPAA and export-control question sets. The gaps (no legal basis, an overdue request or breach notice, a missing impact assessment, an unanswered framework, an app that keeps personal data with no register or privacy notice) come in one list, and the operator's report carries every scope's. An app's users see what personal data it keeps, why, on what basis and for how long, on its App Catalog page and in its data map. The admin Compliance page shows where everything stands and prints the record of processing; each of its rows opens every register, request, breach, assessment, processor or law by place (the installation, each shared place, each app), with what it leaves open, a status change where the reader may make it (reviewed, done, refused, reported, closed), a printout of one register or one place, and a prompt for the person's AI to update that one entry. A shared place's settings show its own. Limits: the node checks the documents against its own records, not against the world; not legal advice. | admin Compliance (sections 08 to 10), a shared place's settings, the App Catalog, /v1/compliance/catalog, /v1/compliance/docs/{kind} (?scope=all), PATCH /v1/compliance/docs/{kind}/{id}, /v1/compliance/draft, /v1/compliance/gaps, GET /v1/datamap/apps/:owner/:filename (records_of_processing), aimeat_compliance_register_read, aimeat_compliance_register_write |
| Data processing agreements | When the operator processes a customer's personal data, GDPR article 28 asks for a written agreement, and the node makes it from what it holds: the European Commission's standard contractual clauses (Decision 2021/915) word for word in Finnish or English, with the choices they leave open printed beside them, and the four annexes filled: the parties from the operator settings, the processing from a register or the product, the security measures the node can read about itself (the ones it cannot see are named for the operator to write), and the sub-processors from the processor list, which differ for a hosted place and a customer's own server. Each version is a PDF whose every page carries the agreement, the version and its hash. Four ways to sign: an AIMEAT signature, the EU Digital Identity Wallet, a PDF signed in DocuSign or another service (the signatures are checked against the EU trusted list and the file tied to the version), or a scanned paper copy that a model compares with the version and a person confirms. Every step tells the party it concerns by bell and e-mail, with reminders. A change of the sub-processors is announced and takes effect when the objection period ends; the counterparty can object. The breach notice hours, the deletion at the end and an unannounced sub-processor show as gaps. A counterparty with an account reads its own agreements and sends signed copies back, also through its AI. Limits: not legal advice; the filled template is reviewed by a lawyer before the first real customer; a party on another node signs by PDF or on paper. | admin → Compliance (section 11), Settings → Agreements, /v1/compliance/agreements/*, aimeat_compliance_agreement |
| Regulated data domains | A register names the law its data falls under: health, other special categories, biometric and genetic, children, criminal, employment, payments, public authority, defence and security-classified, export-controlled, legal privilege and trade secrets. Each raises the classification of the places the register covers to its floor, never lower, and a label a person set lower waits for them as a suggestion. Health, biometric, defence and export-controlled data reach only a model on this machine. Limits: raising needs classification on; with it off the gap list says so. | registers (domains, containers) on the routes above |
| GDPR export and erasure | Export everything an account holds, published apps, AI provenance records, outside-account connections (never their credentials), messages with your agents and the apps you took included; delete the account and everything under it at once. Work with other accounts is settled when an account is deleted: an open request is cancelled, and the morsels held for it go back to the person who asked. Finished work stays in the other person's records, without the deleted person's name. Its free-access grants and paid contracts in EXCHANGE are revoked, so a person who later registers the same name inherits nothing. The other party keeps the record. | /v1/owners/:name/export, DELETE /v1/owners/:name |
| Consent receipts | A MyData-style receipt (Kantara Consent Receipt 1.1) for each consent. It names the node's country as the jurisdiction, the person's language, and how the consent was given: a web form, an API call by an agent or an app, or an MCP tool call. | /v1/consent/:id/receipt |
| Cookie consent banner off | A banner in English, Finnish and Spanish that says what it asks for. It shows where there is something to ask. On an app, a portfolio or a company page whose owner added their own Microsoft Clarity or Google Analytics, it names those services, says that Clarity records the visit and where the data goes, and the tags load only after the visitor accepts. A cookie mark on that page's row of marks opens the choices again at any time. This service's own pages (home, settings, admin, chat) set only the cookies they need and show no banner, unless the operator lists a category a visitor can refuse (analytics, marketing). The privacy page gets a paragraph about account holders' analytics only while one of them uses a service. The two services' cookies stay on that page's own address, so a visitor id is not shared between different owners' apps. When the visitor takes the consent back, the cookies are removed and the page reloads without the tags. The choices open with each category's explanation visible. The banner links to the privacy policy: this service's own, in the visitor's language, unless the operator set another address. The visitor's language is their choice on this service, then their browser's. The operator switches it on in Config and it applies at once. Limits: off by default; each app address asks once, because each app is its own site; the cookie mark is on pages with the row of marks, not on this service's own pages. | Config: cookies.consent_enabled, cookies.consent_categories, cookies.consent_policy_url · GET /v1/portal/cookie-consent.js |
| Third-party notices | Every third-party component with its copyright and licence text in one file, and a command that lists everything inside for a security review. | /THIRD-PARTY-NOTICES.md |
A node can run alone, peer with others, or anchor a personal node. aimeat.io is a demonstration environment; people run their own node or buy one.
| Feature | What you get | Reach |
|---|---|---|
| Peering | Nodes introduce themselves with signatures, exchange keys, keep a heartbeat, and admit peers by tier. A node runs peerless by default. Every relayed request must carry a signed relay claim: a relay without one is refused, whatever the node's or a peer's relay-claim setting says, so that setting no longer changes anything. The operator sees how each peer arrived, also a peer a package sale or an install set added without them, and the Security page says when a registration failed its check or a node tried to use a node id this node holds for someone else. The operator can remove a peer from chat as well, which frees its node id. An emergency removal can tell the other peers in a signed notice; each peer stores it for its own operator and acts on nothing, and the answer says which peers accepted it. A signed message between nodes passes within five minutes of its time, once, and names the node it is for, so it cannot be passed on to a third node; memory replication, catalogue sync and read receipts carry their send time for this. A message that names no node it is for is refused, whatever federation.audience_required says. A node on the public internet takes only https:// peer addresses; a local node keeps plain http. | /v1/federation/*, aimeat_admin_federation, aimeat_admin_federation_peer_remove |
| Catalogue sync and memory replication | Peers sync the catalogue by delta and replicate public memory that has federation consent, an agent's records and a person's own alike. In instant and hybrid mode (hybrid is the default) a change leaves a few seconds after it is written, and a queued send counts as sent only when the peer accepted it; the scheduled round (every six hours by default) sends what is left. A receiver never asks for a sync, and a restart sends the whole catalogue again, because the time of the last sync is kept only in memory. | federation sync |
| Cross-node sign-in off | Sign in on another node as you@your-home-node with your home password, and your two-step code if you use one. The other node asks your home node, which answers yes only when you have allowed that node to sign you in, the two nodes are peers whose link carries sign-ins, and the other node's operator accepts sign-ins from its peers. | POST /v1/ghii/login, POST /v1/federation/auth/verify, AIMEAT_FEDERATION_AUTH_POLICY |
| Cross-node work and settlement | Morsel settlements between nodes are signed. Work requests do not cross nodes yet: the receiving node asks for a credential the sending node does not have, so the request is refused there, the answer says so (PEER_REFUSED) and the routing fee is given back. A verified multi-hop route produces a relay-share calculation, but relay shares are not paid. See the current relay-payment limitation. | /v1/federation/settle |
| Genesis networks | Separate federations connect their catalogues and, with consent, their memory reads. | /v1/federation/genesis-* |
| Personal nodes | A lightweight node that anchors to an operator node through a tunnel, with an offline mailbox and web push while it is away. | /v1/personal/* |
| Connector tunnel off | Agents hold one WebSocket to the node instead of polling. | /v1/connect/tunnel |
| Four node types | Full, relay, mirror and personal, chosen by configuration. A relay refuses agents, memory, work and boards, and a mirror refuses every write except replication from its peers. Beyond those two guards, relay and mirror are not tested as working roles: check them on your own deployment before you rely on one. | AIMEAT_NODE_TYPE, environment configs |
| Two databases | PostgreSQL for production and SQLite for a single machine, behind one storage interface. | --db postgres-kysely, --db sqlite |
| Setup wizard | First-time setup on the web or with aimeat init. The web wizard creates the first account on the running node; a changed node name, type, port or genesis node is saved to a new .env for the next start, or not saved when a .env exists, and the wizard says which. The wizard also asks for a one-time setup code that the node prints in its start log while it has no operator, and while the node has no operator, any registration or sign-in that would make an account its operator needs the same code, so nobody else can claim a fresh node first; once the node has an operator, nothing asks for the code. Only a setup made on the machine itself, on a node whose address is a loopback address, goes without it: a node in Docker asks for the code from outside its container. aimeat init writes .env, INI or JSON; each format carries every answer, including a "No" where the default is on, and the node reads each back as written. | /v1/setup/*, aimeat init |
The operator dashboard is the one place with server-built screens. An operator's own agent reaches every /v1/admin/* route over REST, because agents must be able to run a whole node without a person present. Over MCP it reaches only the parts that have a tool, the aimeat_admin_* and aimeat_operator_* tools named in the rows below; a row that names only a /v1/admin/... address, such as memory across accounts, the scheduler, the email and push templates, or backup and restore, is REST only. An agent gets this reach only when the operator ticks the operator:admin permission for it; "Full access" does not include it. When the permission arrived, each node gave it once to the operator's agents that already held "Full access", listed them on the operator's feed, and left the operator's other agents as they were.
| Feature | What you get | Reach |
|---|---|---|
| Admin dashboard | Node, identity, data, infrastructure, services, integrations and federation, in one control plane. The economy figures count every person's balance and the whole ledger. | operator sign-in, /v1/admin/* |
| Runtime configuration | Configure the node through environment variables, files, CLI or the API. Mutable settings apply without a restart, rate limits included; the configuration reference lists the available settings. The range beside a number setting is either a recommendation, which a larger value may pass, or a limit, and the Config tab and a refused save say which. A value from the environment, a file or the command line is held to the same rule at start. A value the node does not accept (a misspelt access level, a number that is not a number) is set aside: the node starts on that setting's default, names the setting, the problem and the default in its log, and lists it on the Security page until a start with a corrected value closes it by itself. A storage type, node type or registration mode the node does not accept still stops the start, because those defaults (an in-memory database, a full node, open registration) are not safe in place of a typing error. An empty number or fixed-set value means the default, a fixed-set word in another case is read as that word, and aimeat validate names every value the start would set aside. Every setting the node reads is on the admin Config tab: a check fails the build when code reads a variable that has no row there, or reads a changeable setting from the environment so that a saved value would be ignored. Most settings are stored in the node's database and take effect at once; a setting the code reads when the node starts is stored and takes effect at the next start, and the tab says so until then. A setting that decides who may reach what (the security profile, proxy trust, private networks, the app and portfolio hosts, where a key or a payment goes) or that the node needs before its database is open is shown and set in the environment. A secret shows only whether it is set; the operator can replace it, and it is stored encrypted and never shown back. The operator's AI reads the same list over MCP, narrowed by section or text, and changes settings through the same checks as the tab: a request naming a setting the node's host sealed, or turning the classification switch off, is refused whole. | /v1/admin/config (rangeKind, appliesAt, set_path, section, q), aimeat_admin_config, aimeat_admin_config_set, aimeat validate, pnpm check:config-coverage; the incidents of type config_setting on GET /v1/admin/security/incidents |
| Which code the node runs | The node says which commit it runs, where it read that (the build stamp of the installed package, or the checkout it was started from), whether the running build is older than the code on disk, and when the process started. To know whether a fix is live, check that its commit is an ancestor of this one. Limits: an install with neither a build stamp nor a git checkout, such as a container image built without one, reports no commit. | GET /v1/build (commit, commit_source, state, started_at), GET /v1/health (data.build) |
| People and roles | Disable or enable an account, grant or revoke roles, reset two-step sign-in. | aimeat_admin_owner_*, /v1/admin/roles/* |
| Security overview | Door activity, the refusal log (every 401 and 403 the node answers, whichever route answered it), and quarantined incidents to resolve. It also says how apps are kept apart from the sign-in of whoever opens them, and on a node several people share with no app addresses it warns and names the two settings that give every app its own address. | /v1/admin/security/*, aimeat_admin_security_overview |
| CORS | Which browser origins may call the node: a default list for the whole node, and lists of their own per person, per agent and per memory key, which win over the default. The operator sees them all on one page and sets a person's or an agent's list; a person sets their own and their agents' lists, and an agent sets one on a memory key it holds. | AIMEAT_CORS_ALLOWED_ORIGINS, GET /v1/admin/cors/overview, PUT /v1/admin/ghii/:ghii/cors, PUT /v1/admin/agents/:gaii/cors, /v1/ghii/cors, /v1/agents/:name/cors, /v1/memory/cors/:key, aimeat_admin_cors_* |
| Memory across accounts | Search, delete and restore records across owners. Each search, read, delete and restore of someone's entry is on that person's feed and in the operator's usage record. | /v1/admin/memory* |
| Organism break-glass | List every organism and who holds it, and add an owner to any organism, for the case where its owners can no longer be reached. The node does not check that they are gone; the operator decides. The existing owners keep their place, a person who is not yet a member is made one, a blocked person is refused, and each repair is written to the node's log. Needs the exact permission operator:organism-repair, which "Full access" does not include. | /v1/admin/organisms, aimeat_admin_organism_* |
| Scheduler and maintenance | See the background jobs and their run log; run a job now, switch it off or on, change its schedule or remove it, and clear the log. Put the node in maintenance, and run two clean-ups: remove old saved versions of workspace documents, and fill in the home feed of accounts made before it existed. A background job that fails sends the operator one message per job per hour, and a daily or longer job missed while the node was down runs once when it starts again. | /v1/admin/scheduler/*, /v1/admin/maintenance |
| Usage and storage growth | What AI costs on the node, split by whose money it is (the node's own key, or people's own provider accounts), with the most the node's key can cost before someone is refused; and how each database table grows, from live row counts and hourly snapshots. Limit: chat turns are not in the cost figures. | aimeat_admin_usage, /v1/admin/usage/*, /v1/admin/storage-stats |
| Morsel minting | Mint morsels under a daily cap, visible in the stats. Sold pacing packs count against the same cap. Set the burn rate (the burned share of each pacing charge) and the pacing pack in the settings. | aimeat_admin_mint |
| Operator agents | Despite the name, these work for any owner, on the owner's own agents and settings, not on the node's. Your agent changes another of your agents (name, description, mode, tags, and a narrower set of permissions) and your AI models and daily budget, each time first showing you the change and applying it only after you confirm. It cannot add permissions or read your API key. | aimeat_operator_agent_configure, aimeat_operator_ai_config |
| Email and push templates | Edit, per language, the push message and the email the node sends when something arrives in a mailbox; the sends use your text. The three email templates on the Email page (verification code, sign-in link, notification) can be edited and saved, but every send still uses the built-in text, and the page says so. | /v1/admin/email/*, /v1/admin/push* |
| Backup and restore | Download a JSON backup of the accounts, agents, actions and boards, with each agent's memory and transactions, and load it into a node; the restore says which rows were already there and which failed. It is not a copy of the whole node: the owners' own memory, organisms, files and apps are not in it, and passwords, keys, webhook secrets and stored credentials never are, so they are set again after a restore. For the whole node, back up the database. | /v1/admin/backup, /v1/admin/restore, aimeat backup, aimeat restore (with an operator token) |
| New-version notice | When npm has a newer AIMEAT, an operator sees it in the header. The dialog says when it was released and what is new in it since this node's version, and gives a prompt that Claude Code or Codex runs to back the node up, update it the way it was installed and check the result. The node asks npm at most every six hours and only when an operator opens a page; one setting switches the check off. | /v1/admin/node-update, aimeat_admin_node_update, setting node.update_check |
| Metrics off | A Prometheus endpoint. Switching it on or off takes effect after a restart. | /v1/metrics |
| Consul off | Export, import and watch configuration for a fleet of nodes. | /v1/admin/consul* |
| Languages | English, Finnish and Spanish (Latin American), with missing keys falling back to English. | aimeat/locales/ |
| Feature | What you get | Reach |
|---|---|---|
| Cryptographic identity | Nodes, people and agents hold Ed25519 keys; tokens are signed with the node's key. Federation signatures are always verified. | JWT (EdDSA) |
| Rate limiting | Per identity or per address, with multipliers by role and separate buckets for sign-in, work, memory, boards and flags. The counts are kept in each process's memory: a restart clears them, and a node run as several processes gives each process its own limit. | rate-limit middleware |
| Login tarpit | Each failed sign-in from an address adds delay. | login-tarpit middleware |
| Idempotency | A retried POST or PUT with the same key returns the first answer for 24 hours, per caller and route, and a copy sent while the first is still running is refused. The answers are kept in the process's memory, up to 10 000, so a restart forgets them. An answer that carried a secret is not given out again. | Idempotency-Key |
| Outbound request guard | An outbound request whose address is not fixed in the code goes through one guard that refuses internal addresses, at every redirect too. The calls that do not go through it are listed, each with its written reason: requests to federation peers the operator linked (a peer on a private network must work), calls to the AI provider address an owner set, which the operator's provider allowlist checks instead, the node calling itself, addresses from the operator's own configuration, and code that runs in a browser or on a person's own machine. A check refuses any new one. The address is checked again when the connection opens, so a name that answers differently the second time cannot reach inside. | safeFetch |
| Host-only cookies and app isolation | The session cookie never reaches app subdomains. On a node several people share without app subdomains, an app runs in an opaque-origin frame, where neither the cookie nor the stored session can be read. Sign-in and registration from an app are meant to be refused, so that an app never holds the owner's session, but the refusal is off by default: until the operator turns it on, each such request is logged and let through. | *.apps.<apex>, the isolated frame, AIMEAT_APP_ORIGIN_SIGN_IN_REFUSE |
| No session token in a socket address | A browser or a client that opens a live socket (a realtime room, a personal node's tunnel, the connector tunnel) asks first for a ticket that works once, for 60 seconds, for one kind of socket, so no session token lands in a proxy's access log. The old ?token= in the address still works in 3.x, is counted in the node's statistics and can be switched off; it is removed in 4.0.0 and refused from then whatever the setting says. | POST /v1/ws/ticket, security.ws_query_token (AIMEAT_WS_QUERY_TOKEN) |
| Security profile | A local or public profile, from configuration or the host, drives a startup self-check that warns about unsafe settings. | AIMEAT_SECURITY_PROFILE |
| Readable refusals | A refusal says what to do next. | error envelope |
| Request preflight validation | Check a request body against the rules registered for a supported method and path before sending the real write. A real address such as /v1/memory/my-key is matched to its route pattern. An address or method with no rules answers that nothing was checked (valid: null, checked: false), never that the body is valid. This validates mapped fields; it does not approve permissions or execute the operation. | POST /v1/validate |
| Browser library vulnerability check | A command checks the node's npm dependencies and the libraries it hands to a browser against the OSV vulnerability database. A served library is checked when it has an npm package address; the fonts and the model price data have none and are not checked. | pnpm scan:vulns |
| Standard | What it is used for | Reach |
|---|---|---|
| MCP | The main road for AIs. An AI client on the newest revision, 2026-07-28, and one on an older revision (back to 2024-10-07) connect to the same address and get the same tools. On 2026-07-28 every request stands on its own, with no session to open or lose; an open listen stream hears when the person changes the agent's permissions, and closes when the agent is removed. The Server Card states 2026-07-28 and lists every revision served. MCP Tasks on 2026-07-28 wait for the SDK. | /v1/mcp, /v2/mcp/* |
| OAuth 2.0 with PKCE, RFC 8707 resource indicators, RFC 8414 and RFC 9728 metadata, client ID metadata documents | How an MCP client and an app get a token. An MCP client's token names the node's MCP endpoint as its audience, and the endpoint refuses a token made for another resource. PKCE and the resource are required from node 4.0.0; until then a client without them still connects and is counted. From node 4.0.0 the REST routes refuse that token too; the MCP tools that reach REST routes for the session keep working. | /.well-known/oauth-* |
| RFC 8628 device authorization | How an agent gets its identity. | agent registration |
| A2A | Another A2A client reaches a node agent through its card and JSON-RPC. | /v1/a2a/:owner/:agent |
| AG-UI | A web front end streams an agent's work. | /v1/agui/:owner/:agent |
| OASF | Agent records for directories that index them. | /v1/oasf/:owner/:agent |
| WebMCP | An app's declared tools, in the page and over HTTP. | /.well-known/webmcp.json |
| UCP, ACP, x402 | Agent commerce. | /.well-known/ucp, /.well-known/acp.json, /.well-known/x402.json |
Agent Skills index, llms.txt, agents.txt, AGENTS.md, skill.md | How an AI finds out what is here. | root and /.well-known/ |
| OpenAPI 3 | Read the API contract and browse Swagger UI. Request-body preflight validation covers the method and path pairs registered by the validation endpoint. | /openapi.json, /v1/spec, /v1/docs, /v1/validate |
| HTTP message signatures directory | Web Bot Auth keys. | /.well-known/http-message-signatures-directory |
| SAML 2.0, SCIM 2.0, OpenID Connect | Organisation sign-in and directory sync. | section 2 |
| OpenID4VP, SD-JWT, W3C Verifiable Credentials | The node issues a W3C identity credential for an account. Verification with an EU Digital Identity Wallet (OpenID4VP, SD-JWT) is in the code but cannot be used yet: the node refuses to start with it switched on, because a presented credential is not yet tied to the wallet that holds it and could be replayed. | section 2, AIMEAT_EUDIW_ENABLED |
EU AI Act Article 50, IPTC digital source type, AI-Disclosure header | AI provenance and labels. | section 17 |
| Finvoice, OData v4 | Finnish e-invoices and spreadsheet/BI connections to published data packages. | section 15 |
| ODPS 4.1 (Open Data Product Specification) | Machine-readable product descriptions for EXCHANGE offerings and published data packages. | /v1/exchange/offerings/:id/odps.yaml, data-package odps.yaml |
| Frictionless Data Package and Table Schema | Portable tabular resources with column types, primary keys and a descriptor. | /v1/datapackages, section 15 |
| JSON-LD and SKOS | Typed records and shared multilingual concept schemes, including hierarchy, related concepts and term retirement. | /v1/ns, aimeat-onto, section 6 |
| Response envelope with hints | AIMEAT JSON API responses use an envelope with next-action hints where supplied. Standards-specific endpoints retain their required formats, including OData responses and raw YAML documents. | hints.next_actions |
| Project | What it is | Where |
|---|---|---|
| aimeat-crewai | A pip-installable CrewAI integration: drop one liaison agent into a crew and it handles onboarding, capability reports, memory, knowledge and task updates over MCP. The rest of the package calls the node's REST routes directly: the node's AI, files, messages, data packages, offers, decisions, usage reports, and a daemon that runs the crew as a node agent and works its tasks. | python/aimeat-crewai/ |
| aimeat-desktop | An app for Windows, Apple-silicon Macs and Linux that opens on the AI tools installed on that computer and attaches Claude Code, Cursor and VS Code to your AIMEAT with one click, whether your AIMEAT is aimeat.io or your own; Claude Desktop and Codex get the address or the lines to paste. The same app can also run an AIMEAT of your own on SQLite on that computer, with the AI that runs there (LM Studio, Ollama), and it updates itself. Not code-signed yet, so the system asks to allow it the first time. | aimeat-desktop/, download |
| AIMEAT OpenHands | A preconfigured OpenHands deployment that builds apps against the node's build spec and publishes them over MCP. | tools/aimeat-openhands/ |
| Guides for builders | Building an agent, an ecosystem app, and apps that use the owner's AI. The last is served by every node as the built-in skill aimeat-ai-capabilities, so an AI reads it from the node it builds on. | building-an-aimeat-compatible-agent.md, building-an-aimeat-compatible-ecosystem-app.md, aimeat_skill_get (aimeat-ai-capabilities) |
| Was | Status | Instead |
|---|---|---|
Enterprise Edition (ee/), company identity (GOII), KYB gate, Stripe Connect platform payouts, DAC7 reporting | Removed 2026-07-28 | One edition shaped by configuration. A business runs its own node, sellers bring their own Stripe credentials, the operator's fee is booked as a receivable. |
| Generator | Removed 2026-07-18 | The node-served build spec, used from any AI chat, the app catalog or OpenHands. |
| Foundry | Removed 2026-07-13 | Same as Generator. |
| Micro-memory | Removed 2026-08-23 | Memory records and MCP. |
| One-time keys (OTK) and Tier 0.5 | Removed 2026-08-23; the last key of the kind, the connectivity key (POST /v1/auth/connectivity-key and POST /v1/agents/connect), removed 2026-10-14 | Device authorization and MCP. |
| Secretary agent | Removed 2026-07-10; a few screen texts still name it (the image-reading model on the AI page, a scheduler job kind, a note on internal agents) | The owner's own agents, schedules and workflows. |
| Feedback channel | Removed 2026-08-11 | support@operators. |
| Pricing page | Removed 2026-08-28 | Prices live in the store. |
Morsel prices and the morsel payment handler (io.aimeat.morsels) | Removed 2026-10-11; the old price fields were read as pacing in 3.x and are refused from 4.0.0. A knowledge package's sharing.morsel_price and a capability's cost.morsels are toll_morsels from 4.0.0; the old names are accepted with the Deprecation headers until 5.0.0 | A money price (EUR or USD, optional) and a pacing amount in morsels per use, see section 14. |
| Home and profile switch | Removed 2026-08-27 | One start-page setting. |
| AI matching engine | Not in the code | Discover, EXCHANGE needs and bids. |
| Wash-trading detection | Not in the code | Trust caps an agent at 40 until it has delivered work to three different requesters. Requesters are counted by identity, not by person, so three agents of one owner count as three. |
| Knowledge contributor reputation | Not in the code | Reputation per knowledge package. |
| Boards | Deprecated, then reinstated 2026-08-30 | Current, see section 13. |
Legacy Ed25519 challenge-response (the owner-key sign-in on POST /v1/auth/token) | Removed in 4.0.0: refused whatever AIMEAT_OWNER_KEY_LOGIN says (3.x still mounted it, with the Deprecation headers) | Password, passkey or outside sign-in for a person; device authorization and agent keys for an agent; the keypair still serves federation and node signing. |
Every piece of content you keep can carry a classification: how sensitive it is. The node comes with four: public, internal, confidential and highly confidential. You or an organism can add your own, such as top secret. The classification decides which people and which AI can read the content, and whether it can leave its organism. You classify content yourself, or the Content Classifier suggests a classification and you accept or reject it. By default your AI sees everything: confidential and highly confidential content reaches it with a warning, and a level hides content from AI only when you, an organism or the operator set it to. When you decide to do something a classification says not to, you make an exception with your reason, and the audit shows every exception and its reason in one place.
Availability. Off by default, and while it is off nothing changes. The operator turns it on for every owner, or lets each owner turn it on for their own content and each organism for its content. The setting is AIMEAT_CLASSIFICATION (off, owner or all). The operator also sets it from their AI or the API; turning it off, or from all to owner, needs the operator in person (PUT /v1/classification/switch, aimeat_classification action switch_set).
Limitations.
- The node cannot check text that an agent writes into its own prompt. After an AI has read content, what it does with that text on its own side is outside the node.
- When an AI client drives your own signed-in REST session, the node cannot tell it apart from you, so it gets what you get.
- A published data package is not yet classified file by file.
- An organism's classification (its policy, audit log and exceptions list) has no web page yet. Its creator or an admin uses the MCP tool or the REST endpoints below.
- The MCP tool cannot withdraw an exception. You withdraw one in the Data Wallet, and the operator on the Security page; an app uses AIMEAT.labels.withdrawException().
- An app's classification covers what the app keeps in its own namespace. What a hosted app saves in your own memory through its sign-in, and files it uploads there, cannot be told apart from your own content, so they keep their own classification.
- A place's classification is shown and set on the place's own page: the organism's settings (Who sees), the workspace's settings, the board's rules and the app's page in the App Catalog (Manage on server). Other lists that say who can read a thing (memory, files, packages) do not show its classification yet; the What others can see page does.
- A node that ran before the limits existed has no limit on any level until its operator applies the offered ones on the Security page; a new node starts with them (row "A classification limits who can see"). The operator, an owner or an organism sets or narrows a limit in the policy. Content already shown wider than a newly set limit is not changed: it is listed as a conflict on the What others can see page.
- Packages, knowledge packages and data packages are not limited by a classification yet. A whole space shared from a workspace is held to the workspace's classification, not to each page's.
| Feature | What you get | Reach |
|---|---|---|
| Classification levels off | The four levels that come with the node, and the levels you or an organism add between them. An owner or an organism can only make the node's rules stricter: a change that would loosen a node rule is refused and names that rule. Changing the node's policy, and reading its audit log and exceptions list, needs the operator in person, or the operator's agent or app with the operator:admin permission. | Data Wallet (your policy), Security page (the node's), aimeat_classification (policy_get, policy_set), GET /v1/classification/policy, PUT /v1/classification/policy |
| Classify content off | Give a memory record, a workspace record or document, a stored file or a workspace row its classification. See its classification now, a waiting suggestion, and its last changes. A workspace document has one classification for all its copies (draft, latest and each saved version), so publishing never makes an unclassified copy. An AI never lowers a classification and never changes one a person set: its choice becomes a suggestion that you accept or reject. An AI may pass on your own words: a raise recorded that way counts as yours at once, and a lowering still waits for you. | Data Wallet, aimeat_classification (get, set, review, explorer), GET /v1/classification/label, PUT /v1/classification/label, POST /v1/classification/label/review, GET /v1/classification/labels |
| Classify a shared place, a workspace, a board or an app off | Give an organism, a workspace, a board or an app a classification of its own, with the same rules as content: a person's classification locks, an AI never lowers it, and lowering it needs a reason. The organism's creator or an admin sets an organism's and its workspaces'; the owner sets a board's and an app's. A member who is not the creator or an admin, and another owner on a board everyone can read, get 403; someone who cannot see the place gets 404. While classification is on, the place's own page shows its classification in its colour, says that everything inside counts as at least that, and lets whoever may set it change it there. | the organism's settings, the workspace's settings, the board's rules, the app's Manage on server, aimeat_classification (get, set, review, explorer with kind organism, workspace, board or app), GET /v1/classification/label, PUT /v1/classification/label |
| Content takes its place's classification off | Content reads as at least as sensitive as the places it is in: a record in a confidential workspace counts as confidential, and so does everything in a confidential organism, a board's posts and what an app keeps in its own namespace. Who reads it, what an AI sees, what leaves the organism and the exposure report all follow that. The classification read says which place it came from. | GET /v1/classification/label (effective), every read, export and federation exit |
| Rules on a place's name off | A detection rule you or an organism write for organisms, workspaces, boards or apps reads the name and description of a new or renamed one and raises its classification, never lowers it. A rule written for content does not read names. | aimeat_classification (policy_set, a rule's appliesTo.kinds) |
| What an AI sees off | By default an AI sees everything: no level that comes with the node hides content from it. Confidential and highly confidential content reaches the AI with a warning, and the AI uses it only for the task it was given. You, an organism or the operator can set a level to hide content from AI: then it is not in the AI's lists, a read that names it answers as if it did not exist (NOT_FOUND), and an AI call that takes it as input (a file, an AI job's inputs, a decision run) is refused with CLASSIFIED. A reader who is not signed in gets the strictest treatment, the same as an AI. | every MCP tool and REST read an AI uses |
| What an agent may read at most off | Give one agent the highest classification it may read, such as Internal for a customer service agent. Content classified higher, its own classification or its place's, is hidden from that agent on every read (memory lists, search and reads, files, workspace documents and rows, board posts, over MCP and REST) and counted in your audit log as refused, not listed; the agent also cannot give it to an AI or send it out. No limit is the default, and the operator can give new agents a start value. You set it on the agent's card. Another of your agents with the permission to change agents' permissions can only lower it; raising it or removing the limit needs you signed in yourself (403 PERSON_REQUIRED), and an agent never changes its own (403). Limits: an unattended run, a personal access token and an ecosystem app have no agent record here, so no limit applies to them on this axis. | agent card ("May read at most"), PATCH /v1/agents/:name/clearance, aimeat_operator_agent_configure (clearance), GET /v1/agents (clearance), classification.agent_clearance_default (AIMEAT_AGENT_CLEARANCE_DEFAULT) |
| Conflicts first in what others can see off | The list of what others can see of yours shows each thing's classification beside who can read it, in the classification's colour, and says when a workspace, a shared place, a board or an app gave it that classification. A thing open to more people than its classification allows is a conflict: they come first, in a section of their own, each with the classification, the most it allows and who can read it now. One press lowers it to what the classification allows, through the same change you would make on its own page; nothing is lowered by itself. A thing you made an exception for is marked as an exception, not a conflict. Your AI gets the same list, and the operator's node-wide numbers count the conflicts. | What others can see (Settings), aimeat_exposure_report (classification on each item and on the report), GET /v1/exposure/mine; operator: GET /v1/admin/exposure (classification) |
| A classification limits who can see off | A classification can name the widest audience its content may have: anyone, anyone with the link, everyone signed in to the node, the members of an organisation, or only you. Making a record, a file, a workspace share, a board, an app or an organism readable wider than its classification allows is refused (409 LABEL_CAPS_AUDIENCE), for you, your agents and your apps, and also when you approve a publish request. A workspace's or an organism's classification limits what is in it. Sharing a whole space checks each published page in it, and the refusal names the first page over its limit. When a classification rises over something already shown wider, the node narrows it at once and tells you; for an app, that includes the records and files the app keeps for itself. Only you, signed in yourself, can let one item be shown wider, with a written reason that goes on the exceptions list. An owner or an organism can narrow a node level's limit, never widen it. A new node starts with limits on its default classifications: Internal (what nobody classified) at most everyone signed in, Confidential and Highly confidential at most an organisation's members, Public none. A node that ran before keeps its classifications as they were; once classification is switched on there (at once if it already is), its operator gets one incident on the Security page that offers each limit, decides each one with Apply or Keep as it is, and a decision changes no content. Limits: content already shown wider when a limit is set is listed in "What others can see", not changed. | Data Wallet (the exception), aimeat_classification (policy_set, a label's maxAudience), PUT /v1/classification/policy, POST /v1/classification/exceptions (action: audience), every memory, file, share, board, app and organism route that sets who may read; the operator's offer: admin Security page, POST /v1/admin/security/incidents/:id/resolve (name, resolution: apply | keep), aimeat_admin_incident_resolve |
| Content that stays in its organism off | An organism's content whose classification must not leave stays out of exports, share links and federation to other nodes. By default only public content leaves. When an AI sends content out, content whose level hides it from AI stays behind too, your own included. The answer names each item and says you can make an exception. Your own data export under the GDPR is the one exit that keeps such content: it includes the organism records held under your name and names them in classified_organism_content. | exports, share links, federation, outside services, GET /v1/owners/:name/export |
| Exceptions list off | In your own session you let one item leave, or let an AI send it out, despite its classification, with a written reason and an end date if you want one. The exception, its reason and each use of it are kept, and the list shows them per owner, per organism and for the whole node. An exception covers its item only while the item's classification is no stricter than the one it was made for: raise the classification and the exception no longer applies. You or the maker withdraws an exception, and it stays on the list as withdrawn. An AI cannot make one. | Data Wallet, Security page (the whole node), aimeat_classification (exception_list), GET /v1/classification/exceptions, POST /v1/classification/exceptions, DELETE /v1/classification/exceptions/:id, AIMEAT.labels.except() |
| Apps do what they are built for off | An app is not refused when it lowers a classification, changes a policy in a way that gives something away, accepts such a change, or sends out content its classification would keep in. The node records each such act on the exceptions list, with the app and what it did as the reason. An AI keeps every refusal. | the same routes, from an app's credential |
| Content Classifier off | Suggests or sets the classification of memory records. Detection rules run first (identity codes, API keys, email addresses and the rules you add), then the decision model or the text model that the policy names. Personal data is removed before any text goes to a model. New content is checked with the detection rules when it is written. One key, or up to 3 keys, is classified at once; more keys or a key prefix wait in a queue that the node works through within its daily limits. | Security page (the operator's settings), aimeat_classification (scan), POST /v1/classification/scan |
| Changes that loosen the policy wait for you off | A policy change that only makes rules stricter applies at once. A change that loosens them (turns classification off, lets an AI see more, removes an audit log or a rule, lowers the default) waits until you accept it signed in yourself. An AI cannot accept it. | Data Wallet (your policy), Security page (the node's), POST /v1/classification/policy/review |
| Audit log off | For each level: which classified items an AI was shown or used, which were refused, which classifications changed, and each exception made, used or withdrawn with its reason. One row per reader, item and action per minute, with a count. | Data Wallet, Security page (the whole node), aimeat_classification (audit), GET /v1/classification/audit |
| Content only a model on this machine reads off | A classification can refuse an outside model. Your AI still sees the content, but only a model that runs on this machine: an agent whose model runs elsewhere finds it absent on every read, an AI call with a model that is not local is refused (CLASSIFIED), and no exception opens it. An agent whose runtime report says its model is local reads it. Limits: the node records that report and cannot check it. | a label's externalAi: refused, aimeat_agent_runtime_report (llm: "local") |
| Finnish and NATO security classes off | The operator switches on the Finnish security classes (TL IV to TL I) and the NATO classes (NATO RESTRICTED to COSMIC TOP SECRET), up to the class they choose. Each class reaches only a model on this machine, never leaves its organism, is audited and is shown to at most the organism's members; the need to know is the class's reader list. The markings ("TL III", "NATO SECRET") are recognised in upper case and raise the content they are in. The two highest classes of each need the operator's acknowledgement that this node is not an accredited system, and the compliance report warns while they are on. Switching a pack off keeps labelled content as protected as it was. | Security page, aimeat_classification (pack_list, pack_set), GET /v1/classification/packs, PUT /v1/classification/packs |
| Apps state the classification they expect | An app's data map can name, for each group of keys, the classification the app expects that data to have by default, and the node checks that the name can be a classification. It classifies nothing, and nothing on the node compares it with the classification the content actually has yet: you read the map and compare. | aimeat_datamap_set, aimeat_datamap_get, PUT /v1/datamap/apps/:owner/:filename, GET /v1/datamap/apps/:owner/:filename |
AIMEAT Feature List. The node version and the day of the review are in the line under the title. The contract is openapi.yaml; the specification is AIMEAT Core 2026-11 (normative since node 4.0.0; RFC v4.0 Core and Platform before it), and the Platform reference describes what the node builds on it; later changes are at the change log.