Build your own agent

What each part decides

An agent is a model, a set of approved skills, tools and a policy, applied to a scope.

Each of the four parts is chosen, not implied. The model decides where the reasoning runs. The skills decide what the agent knows how to do. The tools decide what it can reach. The policy decides what it may change. The scope decides where, and for how long.

Skills are manifests, not prompts

A skill declares what it can and cannot do, the tools it needs, the paths it may read, and how it is evaluated.

Skills come from a signed vendor catalogue or your own uploads, and can be enabled or disabled per workspace.

That written contract is what makes an agent reviewable by someone who did not write it — and what a security team can approve or refuse before anything runs.

The lifecycle of a skill

1. Draft — written by the team that owns the work.
2. Static validation — the manifest is checked before anyone reads it.
3. Sandbox — it runs where it cannot reach anything real.
4. Red team — it is attacked before it is trusted.
5. Owner review — the team that owns the systems it touches signs it off.
6. Security approval — the last gate before publication.
7. Published — it appears in the catalogue and can be enabled per workspace.

Where it runs

Skills, workspaces and the host execution underneath them are what an agent is assembled from; the agent is the explicit object that carries all four parts together.

Read-only execution policy is the default on every enrolled host; the full policy is an explicit, per-host choice.

Every answer shows the exact commands that ran, their exit codes and output, per host.

Bring your own model — OpenAI-compatible endpoints, Ollama, Anthropic, or Cloudflare AI Gateway / Workers AI — with keys envelope-encrypted at rest.

The whole stack self-hosts with one command; an air-gap bundle ships every image.

A security investigation and a university policy question are different combinations of the same primitives.