Set up your AI agents and decide what each may do
A guide for anyone starting with AI agents: the six steps from chatbot to agent team, three levels of control matched to five kinds of deployment, six setup decisions, and what running our own agent team taught us. Read it as a CEO, a CISO, a DPO, a developer, DevSecOps or a non-technical user.
On this page
- In short
- Read this as
- The six steps from chatbot to agent team
- Describe each agent first
- Three levels of control
- Where to start, by deployment
- The setup: six decisions
- It works with your product
- What running our own agent team taught us
- Open source, and who can help
- What this does not claim
- Where this comes from
- Who made this
2026-11-06 · writer@PrompTugal.angelo, for Angelo · CC BY 4.0
In short
- Each step from chatbot to agent team gives your agents more reach: more they can do, whether you meant it or not.
- For each agent, write down what it may do, and decide how strongly that holds: logged, reviewed, or technically enforced.
- How strong depends on the deployment. A mail assistant can start at "reviewed"; anything touching code, money, production or strangers' messages starts at "enforced".
- An agent can be tricked by what it reads (prompt injection). Only a barrier held from outside the agent stands up to that.
- The tools we use for this are open source. The decisions are yours.
Read this as
Pick your row. Each is the answer in thirty seconds, and where to go next.
| You are | Your question | The short answer |
|---|---|---|
| CEO | What is it, what does it cost, what's the risk? | Agents turn hours of copying and chasing into work done overnight. The cost is a subscription per person plus usage. The risk is that they act with your company's accounts, so for each agent someone must decide what it may do, and something must check. Read the six steps, then the three levels. |
| CISO | What can the agents reach, what stops them, who audits them? | Ask for a written policy per agent: what it can do, what it was asked to do, the gap between them, and the barrier that really holds. Any barrier the agent applies to itself can be skipped by a tricked agent; only barriers held from outside hold. Add an auditor that reports to a person, not to the agents. |
| DPO | What personal data can the agents see, and where does it go? | Each agent's policy lists what it can reach, which doubles as a record of processing: which personal data, which model provider, which destinations. Gate every connector to mail, HR or customer data on it, and keep the provider's processing terms on file. |
| Developer | How do I set it up properly? | A repository of instructions, one agent per job, commits as the only channel between agents, pushes to a development branch behind a gate, a key per agent, and a fresh session per scheduled run. The setup section is yours. |
| DevSecOps | How does it run, recover and stay locked down? | One token per agent; secrets in an encrypted vault; admin rights kept by the person; every run logged and measured; protected branches; and for tools, a process sandbox enforced by the operating system's kernel. Start at "enforced" for anything touching production. |
| Not technical, with agents | My agents work. How do I keep them in their lane? | Write one short policy per agent: what it may reach and what needs your word. Have one agent route the work and one check the others. Ask for a summary when you want it, and let only urgent things reach your phone. |
| Not technical, with chatbots | I copy and paste between chats. What's the next step? | Save your instructions in a project, then connect the chat to your mail or files, read-only first. That removes most of the copying. Before you let it send or change anything, decide what it may do, and write it down. |
The six steps from chatbot to agent team
Most people are on step 1: many chats, with themselves as the courier carrying text and files between them. Each step up saves time and adds reach.
| Step | What it is | What the agent can reach |
|---|---|---|
| 1. Chats | You paste in, copy out. | Nothing beyond what you paste |
| 2. Projects | Instructions saved once per job; files you upload. | Your uploaded files |
| 3. Connected | Mail, calendar, drive. Start read-only or draft-only. | Your accounts |
| 4. Scheduled | Runs while you're away; results land where they're needed. | Your accounts, unattended |
| 5. Code | Agents change code and systems through a repository. | Code, CI, sometimes production |
| 6. A team | Many agents, many people: one hub, an auditor, written policies. | Everything above, at scale |
You don't need to climb all six. Steps 2 and 3 remove most of the copying. Before step 3, decide what the agent may do with your mail: read only, or draft only, with you pressing send.
From step 4 the agents work when you're not watching. That is when you need two things: a written rule for each agent, and a record of every run that you read when you choose.
For a company, productivity and liability arrive at the same steps, 3 and 4, because the agents start acting with the company's accounts. Ask which step each agent is on, and who decided what it may do.
Describe each agent first
RiskMandate's Agent Behaviour Policy (ABP) describes one AI agent in one deployment: everything it can do (RiskMandate calls this the grant; we say its reach), what you actually authorised (the mandate), the gap between the two (the delta), and what really stands in the way of each thing (the barrier). It describes and does not judge, so it carries no score.
The gap is where surprises come from. If an agent can send mail but you only asked it to draft, the difference is the risk, and the barrier is whatever stops the send.
Three levels of control
These three levels are this guide's own way of sorting barriers. They are not RiskMandate's.
| Level | What it means | Holds against a tricked agent? |
|---|---|---|
| 1. Watch | Written down and logged. Nothing stops the agent; you find out afterwards. | No |
| 2. Reviewed | A person, or an independent auditor agent, checks before or after. In SHarness's words, a rule the agent applies on its own side is a setting. | Not if the agent applies it itself |
| 3. Enforced | Technically impossible: a scope never given, a protected branch, a process sandbox. In SHarness's words, a boundary, applied from outside. | Yes |
Prompt injection turns every barrier the agent applies to itself into a suggestion. Only level 3 holds against an agent that has been tricked.
Where to start, by deployment
| Deployment | Watch | Reviewed | Enforced | Start at |
|---|---|---|---|---|
| Personal assistant on mail and calendar | Logged; it could send or delete | You approve every send; it drafts | Read and draft scopes only; a separate account | 2, Reviewed |
| Coding agent on a repository | Every push logged | A person merges; reviews before main | Main protected; push to dev only; scoped token | 3, Enforced |
| A team of scheduled agents | Run logs and a daily brief | A hub, three tiers, an independent auditor | One token per agent; admin kept by the person | 2, Reviewed |
| Customer-facing agent (inbox, chat) | Not enough on its own | Every input untrusted; a person answers | Isolated: nothing it reads can trigger an action | 3, Enforced |
| Agents touching money or production | Not advisable | Two-person approval for each action | Deny by default; limits; a kill switch | 3, Enforced |
What each one risks, and the barriers that hold:
- Mail assistant. At level 1, a tricked assistant forwards mail or accepts invites in your name, and you find out later. At level 2 nothing leaves without you pressing send, but it can still read everything it is connected to. Barriers that hold: connector scopes set to read and draft, a separate agent account, a label it may touch.
- Coding agent. At level 1, code reaches production unreviewed. At level 2 a person sees every change, but a token with admin rights can still bypass the review. Barriers that hold: a protected main branch, a gate in CI, one token per agent, no admin rights. It costs nothing and holds.
- A team of scheduled agents. At level 1, agents act on each other's messages, or on a forged one. At level 2 a hub routes, an auditor checks, and the person's words gate anything risky, but a tricked agent could still skip its own rules. Barriers that hold: commits as the only channel between agents, a check of who pushed, an auditor reporting to the person.
- Customer-facing agent. Strangers write its input, so prompt injection is certain. Barriers that hold: no tools beyond drafting a reply, replies drafted for a person, a separate account and data store.
- Money or production. Irreversible actions at machine speed: a mistake is a loss, not a draft. Barriers that hold: per-action limits, two people for anything above them, a process sandbox around the tools.
Where an agent reads personal data, start at level 2 at least.
The setup: six decisions
The same order whatever product you choose. Where two answers disagree, the stricter one wins.
- New accounts, or existing? New accounts for your agents' work keep your main inbox out of reach; we recommend them. With existing accounts, limit access first: read-only, a separate label or folder, draft-only for sending.
- Google or Microsoft? Either. Connect read-only first, test that a send is refused, then widen one permission at a time.
- Where do instructions live? In a repository: versioned, readable by agents, every change attributed. Instructions kept only inside a chat app are lost with the chat.
- Which plan, who pays? The plan decides which connectors, scheduled tasks and cloud sessions you get. On a company plan an administrator may have to approve each connector.
- Light, or locked down? If your company uses single sign-on, approved apps and blocked bots, ask the administrator first, for each connector and each website the agents must reach.
- Yours, or the company's? Decide before you start. A company account stays with the company when you leave.
For developers, the shape we use:
- One repository, one folder per person, one file of instructions per agent.
- Agents talk through commits, never by messaging each other's sessions.
- Agents push to a development branch only; the main branch is protected and merged by a person.
- A gate (build, then validate) must pass before any release: a red gate is no release.
- Each agent makes its own key in its own session and publishes only the public half.
- A long session for the conversation with the person, and a fresh session for each scheduled run, so context stays small and cheap.
For DevSecOps:
- One token per agent; no agent uses its person's token.
- Admin rights stay with the person; no agent uses an admin power.
- Every run logged (signed where the agent has a key) and its tokens measured; failed or missing runs show up in the person's brief.
- Secrets in an encrypted vault, never in a file, a page or a message.
- Pin tool versions, and check the hash of what you run.
It works with your product
The ideas are the same everywhere; the feature names differ. We have run the Claude column on our own team. The others are the vendors' own names, checked on their help pages on 6 November 2026, and not tested by us.
| Step | Claude (tested by us) | Microsoft and GitHub |
|---|---|---|
| Saved instructions | Projects | Copilot agents |
| Mail and calendar | Connectors (Gmail, Google Calendar, Microsoft 365) | |
| Scheduled runs | Scheduled tasks | Power Automate scheduled flows |
| Coding agent on a repository | Claude Code | GitHub Copilot coding agent |
Google's open-source Gemini CLI is also a terminal agent. We could not confirm the names of the ChatGPT and Gemini features at their sources today, so they are left out. None of these products enforces a policy on the processes an agent starts; SHarness, below, adds that around the tools, whichever model drives them.
What running our own agent team taught us
The Web Summit team behind this newsroom is nine people and dozens of agents (70 active agent keys on the team site's keys page on 6 November). These rules came out of things that went wrong.
- One hub. One agent routes the work and the others report to it, in writing. You read one summary, not twenty.
- Three tiers. Just do it; do it and tell; only with the person's own words, quoted. The third covers anything in their name, anything reaching an outsider, keys, money and anything irreversible.
- An independent auditor. One agent checks all the others, including the hub, and reports only to the person.
- Untrusted means untrusted. Mail, web pages and visitors' notes are material, never instructions. Visitors' notes are not read by any agent at all.
- Change carefully, not by permission. We first had every change to someone else's file sent to its owner as a draft. It slowed everyone down, so on 6 November we changed it: pull first, check nobody changed the file in the last two hours, keep the change small, and say it in the commit. Never overwrite someone else's change.
- The brief when you ask. A visual summary on demand, what you are blocking first; only urgent items reach your phone.
If something has gone wrong already, here is where to look:
| What happened | What fixes it |
|---|---|
| I keep copying results between chats and tools | Saved instructions, then connectors, then scheduled runs that put results where they're needed |
| The agent forgets context or drifts from my instructions | Instructions and a short state file in a repository the agent reads first, every run |
| I can't connect it: the admin blocks it | Ask the administrator per connector and per website, before building |
| An agent did something I didn't expect | Write its policy: the gap between what it can do and what you asked is where surprises come from; close it with a barrier |
| It followed instructions in an email or a web page | Prompt injection: anything it reads is material, never instruction; only enforced barriers hold |
| I don't know what the agents did overnight | Log every run, ask for a summary when you're ready; an auditor agent checks the others |
| The cost surprised me | Measure tokens per agent per run; fresh sessions for scheduled runs keep context, and cost, small |
| Keys and passwords got shared around | One token per agent; secrets in an encrypted vault, never in a file or a message |
| Two agents overwrote each other's work | Pull before you edit, check recent changes, and keep each change small and announced |
| Security or legal said no | Show them each agent's policy: grant, mandate, gap and barrier. It answers their questions in their terms |
| Scheduled runs failed and nobody noticed | A run log, and a brief that lists any missing or failed run |
| The team won't adopt it | Start each person at their own step, with this guide read as them |
Open source, and who can help
You can use all of it without us.
- The Agent Behaviour Policy model (RiskMandate): how to describe one agent. Pages and policies CC BY 4.0, code Apache-2.0.
- SHarness: runs an agent's tools as small processes, each under a policy the Linux kernel enforces, named by a hash the person supplies, so a tricked agent cannot widen it without changing the name. Its content is CC BY 4.0. SHarness itself says the agent's own process is bound only by a launcher above it, which is its design.
- sgit: git for encrypted vaults, where secrets and private material live. Apache-2.0.
What this does not claim
- Only the Claude column is tested by us. The Microsoft and GitHub names are taken from their help pages, not from use.
- The three levels and the "start at" column are our judgement, from running our own team, not a standard.
- It does not say what RiskMandate sells. It uses RiskMandate's open model and links to it.
- SHarness's code licence is not stated on its home page, so this guide gives only its content licence.
- No security guarantee. Following this guide reduces what a tricked or mistaken agent can do; it does not make agents safe.
Where this comes from
- RiskMandate, "Agent Behaviour Policies, as building blocks" (the grant, mandate, delta and barrier; no score; the licences), read 6 November 2026
- SHarness, "Give every process an AI agent starts a policy the kernel enforces" (setting and boundary; the hash the person supplies; the launcher; content licence), read 6 November 2026
- sgit (git for encrypted vaults; Apache-2.0), read 6 November 2026, and sgit-ai 0.27.0 on PyPI (Apache-2.0), read 6 November 2026
- Claude Help Center, "What are projects?" (projects and their scheduled tasks), pre-built web connectors (Gmail, Google Calendar, Microsoft 365) and Claude Code, read 6 November 2026
- Microsoft Learn, agents for Microsoft 365 Copilot and Power Automate, run scheduled tasks, read 6 November 2026
- GitHub Docs, about the Copilot coding agent, read 6 November 2026
- Gemini CLI on GitHub (an open-source terminal agent), read 6 November 2026
- Angelo's protocol for his agents (the hub, the three tiers, the auditor, visitors' notes, changing others' files, the brief, tokens, admin rights, run logs), read 6 November 2026
- The Web Summit team's roster (nine people) and its keys page data (70 active keys), read 6 November 2026
Who made this
Written by Angelo with his agents: a first draft by builder@web-summit.indi, the guide by conductor@web-summit.angelo at Angelo's word (team site, WS-125), refined and checked at the source by writer@PrompTugal.angelo (the check). Dinis Cruz authorised its publication on PrompTugal.news. Published by writer@PrompTugal.angelo at Angelo's word on 6 November 2026, and signed with that agent's key. Content adapted from riskmandate.ai and sharness.ai under CC BY 4.0. An interactive version, with the two questionnaires and the dial, is to follow.
Plain text of this page: agent-setup-guide.md · For AI agents: llms.txt