Build and share

Build a governed AI agent

Your Mind is your team's shared Mensara workspace for saved information and work. An installed AI agent is a program that does a defined job there with help from an AI model, the service that generates its response. You decide what information it may use, what it may propose and how much it may spend. This guide explains how to turn one small job into a tested, reviewed agent and check its first useful result.

Contents

How an installed agent works

A connected agent is the AI tool you use in a chat or coding application to work with your Mind. An installed agent is a separate program that runs on the server hosting your Mind and is registered with its own identity and permissions. A schedule can start it without you keeping a chat open. Connecting a chat tool alone does not install this kind of program.

The program reads the information its job needs, asks an allowed model to help and proposes its result. The Mind checks its access and spending limits. Governed means the agent works within those agreed boundaries and review rules; it cannot give itself more permission.

For a first practice job, it might summarise one clearly fictional note and propose the summary in a disposable area. The person setting it up checks both the original note and the proposed summary. Choose the right kind of help explains when a written procedure or a loop might be a better fit.

Diagram

Your chat tool and the installed agent

They are separate programs. Connecting your chat tool does not install an agent.

In words

You use a connected chat or coding tool to work with your Mind and prepare an agent. The installed agent is a separate program on the server hosting your Mind, with its own identity, permissions and budget. A schedule can start it there without your chat staying open. It reads only information it is allowed to use, calls an owner-configured allowed model and proposes its result under the Mind’s review rules. Personal chat access to a model does not supply that installed-agent configuration.

Before you start

Building this kind of agent needs a coding client that can create files and run tests. A chat-only client can help describe the job, but must hand the build to someone with those tools.

Ask your coding agent to find the app-engineer skill. A skill is a written procedure; this one supplies the current templates and rules for building an installable program. If it is unavailable in your Mind, ask the owner which supported authoring route to use.

You also need permission to propose the program's files, an authorised reviewer and installer, and an owner-configured model the installed agent is allowed to use. Access to a model in your personal chat does not by itself supply that installed-agent setup.

Define one useful result

Agree the input, output, schedule and maximum spending over the agent's lifetime. Name the person who handles a failed or doubtful result. Start with synthetic practice information before relying on it for real work.

A program that follows fixed rules without a model is a deterministic job. It can use the same installation route, but testing it does not show that an AI model can run through your agent's allowed setup.

Build and test the program

The installable files are called a bundle. This route uses two files: a manifest describing the program's access, limits and schedule, and a Python file containing its instructions for execution.

  1. Have your coding client read the current app-engineer skill and the rules it links to.
  2. Adapt its template to the agreed job with the smallest necessary permissions.
  3. Run the supplied tests and tests of the intended result. These local tests are called offline tests because they do not prove a real scheduled run on the Mind.
  4. Inspect the exact two files before proposing them for review.

Keep passwords and keys out of those files. Model and service connections are configured separately by an authorised owner.

Review, then install

Submit the bundle once and keep its proposal reference. A reviewer checks the exact files, access and limits. On the delegated admin route, the author cannot approve or install their own bundle; the owner has an exception under the product's rules.

Approval saves the reviewed files. Installation is a separate step that registers the program so it can run with the agreed access. Have the installer check its schedule, model setup and lifetime budget before allowing a scheduled run. Install an approved agent explains that stage.

Check the real output

The scheduler is the service that starts work when its configured time or trigger arrives. Wait for that normal route, then inspect the agent's proposed result and any failure report.

A result that is held is waiting for review. An applied result has been saved under the Mind's rules; open the saved record and check it. Installation, successful local tests and a program ending without an error do not by themselves show that the intended job worked.

Diagram

Check each stage’s result

Tests, approval and installation are milestones. Inspect a real scheduled output too.

In words

Use a coding client to build the bundle and run the offline tests. An authorised reviewer checks the exact proposed files and saves the approved bundle. Installation then registers the program with its agreed access, model configuration, schedule and lifetime budget. Wait for a normal scheduled run and inspect its real output. A held output still needs review. Passing offline tests, approving the files or installing the program alone does not prove that its intended job ran successfully.

If a step is blocked

Ask the coding agent to identify the stage it reached and the missing requirement. It may need the skill, a test fix, review, installation permission, model setup or remaining budget. Keep the proposal and app references so the authorised person can resume the same work.

Some connected clients cannot perform installation and other management steps. Use the supported operator handoff at that point. Remove a practice-only installation when testing ends, and restore any schedule shortened for the test.

Related

Choose the right kind of help · Install an approved agent · Build your first recurring workflow with a loop

Practical guides for people and agents

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## 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 a governed AI agent

Guides · Build and share · [How it works](https://app.mensara.ai/how-it-works)

Your Mind is your team's shared Mensara workspace for saved information and work. An installed AI agent is a program that does a defined job there with help from an AI model, the service that generates its response. You decide what information it may use, what it may propose and how much it may spend. This guide explains how to turn one small job into a tested, reviewed agent and check its first useful result.

[Page as Markdown](https://app.mensara.ai/how-it-works/build-an-agent.md)

[Operating procedure](https://app.mensara.ai/how-it-works/build-agent-procedure)

## How an installed agent works

A **connected agent** is the AI tool you use in a chat or coding application to work with your Mind. An installed agent is a separate program that runs on the server hosting your Mind and is registered with its own identity and permissions. A schedule can start it without you keeping a chat open. Connecting a chat tool alone does not install this kind of program.

The program reads the information its job needs, asks an allowed model to help and proposes its result. The Mind checks its access and spending limits. **Governed** means the agent works within those agreed boundaries and review rules; it cannot give itself more permission.

For a first practice job, it might summarise one clearly fictional note and propose the summary in a disposable area. The person setting it up checks both the original note and the proposed summary. [Choose the right kind of help](https://app.mensara.ai/how-it-works/right-kind-of-help) explains when a written procedure or a loop might be a better fit.

### Your chat tool and the installed agent

They are separate programs. Connecting your chat tool does not install an agent.

#### In words

You use a connected chat or coding tool to work with your Mind and prepare an agent. The installed agent is a separate program on the server hosting your Mind, with its own identity, permissions and budget. A schedule can start it there without your chat staying open. It reads only information it is allowed to use, calls an owner-configured allowed model and proposes its result under the Mind’s review rules. Personal chat access to a model does not supply that installed-agent configuration.

## Before you start

Building this kind of agent needs a coding client that can create files and run tests. A chat-only client can help describe the job, but must hand the build to someone with those tools.

Ask your coding agent to find the **app-engineer** skill. A skill is a written procedure; this one supplies the current templates and rules for building an installable program. If it is unavailable in your Mind, ask the owner which supported authoring route to use.

You also need permission to propose the program's files, an authorised reviewer and installer, and an owner-configured model the installed agent is allowed to use. Access to a model in your personal chat does not by itself supply that installed-agent setup.

## Define one useful result

Agree the input, output, schedule and maximum spending over the agent's lifetime. Name the person who handles a failed or doubtful result. Start with synthetic practice information before relying on it for real work.

A program that follows fixed rules without a model is a deterministic job. It can use the same installation route, but testing it does not show that an AI model can run through your agent's allowed setup.

## Build and test the program

The installable files are called a **bundle**. This route uses two files: a manifest describing the program's access, limits and schedule, and a Python file containing its instructions for execution.

1. Have your coding client read the current app-engineer skill and the rules it links to.
2. Adapt its template to the agreed job with the smallest necessary permissions.
3. Run the supplied tests and tests of the intended result. These local tests are called **offline tests** because they do not prove a real scheduled run on the Mind.
4. Inspect the exact two files before proposing them for review.

Keep passwords and keys out of those files. Model and service connections are configured separately by an authorised owner.

## Review, then install

Submit the bundle once and keep its proposal reference. A reviewer checks the exact files, access and limits. On the delegated admin route, the author cannot approve or install their own bundle; the owner has an exception under the product's rules.

Approval saves the reviewed files. **Installation** is a separate step that registers the program so it can run with the agreed access. Have the installer check its schedule, model setup and lifetime budget before allowing a scheduled run. [Install an approved agent](https://app.mensara.ai/how-it-works/install-an-agent) explains that stage.

## Check the real output

The **scheduler** is the service that starts work when its configured time or trigger arrives. Wait for that normal route, then inspect the agent's proposed result and any failure report.

A result that is **held** is waiting for review. An **applied** result has been saved under the Mind's rules; open the saved record and check it. Installation, successful local tests and a program ending without an error do not by themselves show that the intended job worked.

### Check each stage’s result

Tests, approval and installation are milestones. Inspect a real scheduled output too.

#### In words

Use a coding client to build the bundle and run the offline tests. An authorised reviewer checks the exact proposed files and saves the approved bundle. Installation then registers the program with its agreed access, model configuration, schedule and lifetime budget. Wait for a normal scheduled run and inspect its real output. A held output still needs review. Passing offline tests, approving the files or installing the program alone does not prove that its intended job ran successfully.

## If a step is blocked

Ask the coding agent to identify the stage it reached and the missing requirement. It may need the skill, a test fix, review, installation permission, model setup or remaining budget. Keep the proposal and app references so the authorised person can resume the same work.

Some connected clients cannot perform installation and other management steps. Use the supported operator handoff at that point. Remove a practice-only installation when testing ends, and restore any schedule shortened for the test.

## Related

- [Choose the right kind of help](https://app.mensara.ai/how-it-works/right-kind-of-help)
- [Install an approved agent](https://app.mensara.ai/how-it-works/install-an-agent)
- [Build your first recurring workflow with a loop](https://app.mensara.ai/how-it-works/first-loop)

Previous page: [Help another agent continue the work](https://app.mensara.ai/how-it-works/continue-the-work)

Next page: [Install an approved agent](https://app.mensara.ai/how-it-works/install-an-agent)

Check the bundle, granted scope and first useful result.

[Join the waitlist](https://app.mensara.ai/#waitlist)