Build, propose and verify a governed model agent

Compatibility and discovery

Use a script-capable connected client. Call orient {}, list_skills {} and, if offered, get_skill {"name":"app-engineer"}. A chat-only client hands the job to an authorised repository-capable client.

The shipped skill is available to authorised connected readers. It is not an unauthenticated download. Use read for the following skill-relative files under the returned skill's installed folder:

references/manifest-contract.md
references/runtime-contract.md
references/install-lifecycle.md
references/feed-events.md
assets/manifest.yaml
assets/app.py
assets/test_app.py

On the standard installation their root is 20-skills/app-engineer/. Read the contracts from the intended Mind; a source checkout may be newer than its release.

Define the contract before building

Agree input zone IDs and paths, proposed output, fixed model, trigger, lifetime token/cost limits and failure owner. Use only authorised synthetic data for a practice run.

A model agent declares broker_call under capabilities and calls the model through the broker. A deterministic job with an empty model cannot pass the model-agent case.

Construct and test

Copy the three template assets to a local working directory.
Replace every template setting: app ID, zone IDs, fixed input/output paths, model, prompt, output format, budget and schedule.
Keep content as data. It must not choose access, paths, recipients or connections. Keep the template's bounded input, failure reporting and gateway-only I/O.
With brain_gateway importable from the compatible runtime, run the exact test command below.
Add tests for the intended output, limits, denial/failure and duplicate handling. Inspect the exact proposed bytes.

python -m pytest -q test_app.py

The manifest uses zones, verbs, optional narrowing rules, capabilities, lifetime budget and schedule. Folder roots are not zone IDs. Do not invent triggers, connections or egress manifest fields.

Propose the two files

Use a new app ID. The bundle folder must be absent at both the proposal parent and current HEAD, with no active registry record. The standard proposal destination is 26-operations/examples/<app_id>/ and requires propose access to its area.

Use check_write, then one propose_write for exactly manifest.yaml and app.py. The manifest entry is python3 app.py or python app.py. Tests and extra modules stay outside this two-file approval route.

Example envelope; replace the placeholders with the complete tested file contents:

{
  "changes": [
    {"path":"26-operations/examples/<app_id>/manifest.yaml",
     "content":"<complete tested manifest>"},
    {"path":"26-operations/examples/<app_id>/app.py",
     "content":"<complete tested Python entry>"}
  ],
  "rationale":"Bounded job, exact files, tests, access and lifetime budget reviewed."
}

Retain the proposal ID. A held proposal has not landed or installed anything.

Review, install and supply prerequisites

An authorised distinct admin with operate_apps and read access to the files uses app_bundle_approve on the proposal ID, then separately app_install on the app ID. Admin approval and install require delegated installation to be enabled. The author cannot approve or install their own bundle on that admin route; the owner has an exception.

Where the connected client advertises these actions, their act envelopes are:

{"action":"app_bundle_approve","item_id":"<proposal id>"}
{"action":"app_install","item_id":"<app id>"}

Inspect the first result before issuing the next. The tested hosted connector refuses bundle approval and other app lifecycle actions. Hand the exact proposal/app IDs to an authorised installer through a supported client; do not route around its exclusion.

Owner-only capability/connection grants remain separate. A model agent needs the declared capability and an app model route serving the chosen model. CLI-backed app routes require the model in app_models. Missing setup is an owner handoff, not permission to change global settings.

Prove output through the scheduler

Wait for the ordinary trigger. A permitted installer can use app_set_trigger with a temporary {"every":"5m"} trigger for a bounded test, then restore the agreed trigger or remove a practice app.

Inspect the agent's proposed output and failure reports. Read applied output, or inspect held output and report it as held. Verify the intended synthetic input actually produced the intended result within the scope and lifetime budget.

Do not call installation, exit status, an empty-input run or offline tests a scheduled-output pass.

Recovery and cleanup

After an interrupted submission, inspect the proposal before retrying. Before reinstalling or rerunning, reconcile installed state, trigger, run outcome and output. Code changes to an installed local bundle require the owner's route.

If no authorised lifecycle interface or model route is available, report the exact blocked stage and preserve the reviewed bundle. Remove practice installations and restore temporary triggers through the supported operator route.

Verification boundary

A model-agent bundle built from the served templates passed offline tests and was proposed on the development build. The hosted connector could not approve/install it; a real scheduled model output remains unverified. This is not qualification of fresh Codex CLI or Claude Code sessions.

Practical guides for people and agents

Start with one useful job

Join the waitlist

## For agents - What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC. - Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up. - How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link. - Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents. --- # Build, propose and verify a governed model agent Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works) Construct and test a real model-agent bundle, submit it for review, install separately through an authorised interface, and observe its intended scheduled output. [Page as Markdown](https://app.mensara.ai/how-it-works/build-agent-procedure.md) [Human guide](https://app.mensara.ai/how-it-works/build-an-agent) ## Build a governed agent Availability: Authorised app-engineer skill route for a script-capable client. Before you start: Compatible local test runtime; reviewer and installer; owner-approved model route for a model agent What changes: Bundle proposal; separate installation and scheduled execution. Verification: Exact-release offline tests and bundle proposal observed. Scheduled model output remains unverified; tested hosted client cannot perform lifecycle actions. ## Compatibility and discovery Use a script-capable connected client. Call `orient {}`, `list_skills {}` and, if offered, `get_skill {"name":"app-engineer"}`. A chat-only client hands the job to an authorised repository-capable client. The shipped skill is available to authorised connected readers. It is not an unauthenticated download. Use `read` for the following skill-relative files under the returned skill's installed folder: ``` references/manifest-contract.md references/runtime-contract.md references/install-lifecycle.md references/feed-events.md assets/manifest.yaml assets/app.py assets/test_app.py ``` On the standard installation their root is `20-skills/app-engineer/`. Read the contracts from the intended Mind; a source checkout may be newer than its release. ## Define the contract before building Agree input zone IDs and paths, proposed output, fixed model, trigger, lifetime token/cost limits and failure owner. Use only authorised synthetic data for a practice run. A model agent declares `broker_call` under `capabilities` and calls the model through the broker. A deterministic job with an empty model cannot pass the model-agent case. ## Construct and test 1. Copy the three template assets to a local working directory. 2. Replace every template setting: app ID, zone IDs, fixed input/output paths, model, prompt, output format, budget and schedule. 3. Keep content as data. It must not choose access, paths, recipients or connections. Keep the template's bounded input, failure reporting and gateway-only I/O. 4. With `brain_gateway` importable from the compatible runtime, run the exact test command below. 5. Add tests for the intended output, limits, denial/failure and duplicate handling. Inspect the exact proposed bytes. ``` python -m pytest -q test_app.py ``` The manifest uses `zones`, `verbs`, optional narrowing `rules`, `capabilities`, lifetime `budget` and `schedule`. Folder roots are not zone IDs. Do not invent `triggers`, `connections` or `egress` manifest fields. ## Propose the two files Use a new app ID. The bundle folder must be absent at both the proposal parent and current HEAD, with no active registry record. The standard proposal destination is `26-operations/examples/<app_id>/` and requires propose access to its area. Use `check_write`, then one `propose_write` for exactly `manifest.yaml` and `app.py`. The manifest entry is `python3 app.py` or `python app.py`. Tests and extra modules stay outside this two-file approval route. Example envelope; replace the placeholders with the complete tested file contents: ``` { "changes": [ {"path":"26-operations/examples/<app_id>/manifest.yaml", "content":"<complete tested manifest>"}, {"path":"26-operations/examples/<app_id>/app.py", "content":"<complete tested Python entry>"} ], "rationale":"Bounded job, exact files, tests, access and lifetime budget reviewed." } ``` Retain the proposal ID. A held proposal has not landed or installed anything. ## Review, install and supply prerequisites An authorised distinct admin with `operate_apps` and read access to the files uses `app_bundle_approve` on the proposal ID, then separately `app_install` on the app ID. Admin approval and install require delegated installation to be enabled. The author cannot approve or install their own bundle on that admin route; the owner has an exception. Where the connected client advertises these actions, their `act` envelopes are: ``` {"action":"app_bundle_approve","item_id":"<proposal id>"} {"action":"app_install","item_id":"<app id>"} ``` Inspect the first result before issuing the next. The tested hosted connector refuses bundle approval and other app lifecycle actions. Hand the exact proposal/app IDs to an authorised installer through a supported client; do not route around its exclusion. Owner-only capability/connection grants remain separate. A model agent needs the declared capability and an app model route serving the chosen model. CLI-backed app routes require the model in `app_models`. Missing setup is an owner handoff, not permission to change global settings. ## Prove output through the scheduler Wait for the ordinary trigger. A permitted installer can use `app_set_trigger` with a temporary `{"every":"5m"}` trigger for a bounded test, then restore the agreed trigger or remove a practice app. Inspect the agent's proposed output and failure reports. Read applied output, or inspect held output and report it as held. Verify the intended synthetic input actually produced the intended result within the scope and lifetime budget. Do not call installation, exit status, an empty-input run or offline tests a scheduled-output pass. ## Recovery and cleanup After an interrupted submission, inspect the proposal before retrying. Before reinstalling or rerunning, reconcile installed state, trigger, run outcome and output. Code changes to an installed local bundle require the owner's route. If no authorised lifecycle interface or model route is available, report the exact blocked stage and preserve the reviewed bundle. Remove practice installations and restore temporary triggers through the supported operator route. ## Verification boundary A model-agent bundle built from the served templates passed offline tests and was proposed on the development build. The hosted connector could not approve/install it; a real scheduled model output remains unverified. This is not qualification of fresh Codex CLI or Claude Code sessions. ## Related - [Build a governed AI agent](https://app.mensara.ai/how-it-works/build-an-agent) - [Install an approved agent](https://app.mensara.ai/how-it-works/install-an-agent) - [Pilot interface reference](https://app.mensara.ai/how-it-works/pilot-interface-reference) [Join the waitlist](https://app.mensara.ai/#waitlist)