Frontier agents can research, browse, use tools and continue work without a fresh prompt. More useful than a chat window—and capable of carrying mistakes further.
I treat an agent like a worker with a computer: give it a job, a bounded identity, minimum tools, memory appropriate to the role and explicit authority for what it may change.
Agents may read and propose broadly. Authority should remain narrow.
Memory is not policy. A bot is not the system of record.
An independent operating-model exercise. Example roles and workflows are proposed designs, not an employer implementation.
Information exists. Organisational memory does not.
An Account Manager learns that availability changed, documents are missing, a payout is disputed or a promise was made. It might arrive by email, phone, video, in person, hypothetical WhatsApp or platform message.
The note stays on paper, in personal email, or in a CRM another team does not check. A colleague acts without it. The customer repeats themselves, receives a conflicting answer and opens a ticket. The Account Manager is pulled back in.
The agent does not become the memory. It helps move useful information into the memory the organisation already governs.
This is the same missing-owner problem explored in the knowledge and tooling case. The goal is not to read everyone’s mailbox. It is to move useful facts into governed organisational state.
02 / Capture
Capture the event, not everyone’s inbox.
Avoid universal hidden BCC into a shared AI mailbox.
It collects too much: personal or confidential conversations, duplicate attachments, secrets and casual speculation. Retention, correction, deletion and employee-monitoring concerns become harder to resolve—not easier.
Prefer native integration
A business-system connector receives permitted email, calendar or platform-message events and resolves them to known accounts. Extract bounded fields; do not permanently mirror whole mailboxes.
Make capture explicit
“Log to Account”, a dedicated company workflow or structured post-call notes. Meeting capture follows attendee consent and applicable organisational policy.
Journaling is conditional
Only for a justified audit context, after legal and privacy review, including works-council review where relevant. Define retention, access, personal-message exclusion, redaction and audit first.
03 / Memory design
Two kinds of memory.
An agent may remember process. The organisation owns truth.
Agent memory answers “How do I usually perform this job?” Organisational memory answers “What is true right now?” Approved pricing, compliance rules and audit records belong with their accountable source owners.
The bot may remember how to find policy. It may not become policy.
When less memory is better
A narrow research job can use a request, public sources and a temporary workspace: research → cited report → expiry. No internal access or writes. An ephemeral design has less state to govern. Risk determines persistence; dual memory is not universally superior.
04 / Permissions
Permission is a product decision.
A role description is not an access-control boundary.
No general company bot with inherited access to everything. Each job needs its own identity boundary, owner, purpose, data scope, tools, network scope, permitted actions, approval rules, cost/time budget and retention policy.
Illustrative roles and permissions
Team
Useful work
Read access
Write authority
Marketing
Research / campaign drafts
Public web + approved analytics
Draft only
Sales
Account research / meeting brief
CRM account scope
Draft / proposed task
Account Management
Portfolio brief / follow-up / quality flags
Assigned accounts + approved mail context
Notes/tasks behind policy gate
Booking / Care
Case summary / retrieval / reply draft
Ticket + Booking
No money or booking commit
Trust & Safety
Evidence packet / contradictions
Bounded risk / identity view
No final KYC or ban
Finance
Reconciliation explanation
Bounded ledger read
No payout or refund
Platform Ops
Health / workflow analysis
Approved operational read
Controlled admin gate
Leadership
Executive synthesis
Governed aggregates
None
05 / Action classes
Read broadly only within the job. Commit narrowly.
Autonomy should increase only where the blast radius is understood.Four action classes
Class
Examples
Authority
0 · Observe
Public search, approved article, scoped analytics, case summary
No per-action approval inside the approved read scope
Payout/refund, booking, KYC, ban, contract, deployment, public policy
Deterministic checks and explicit human authority; no autonomous promotion by default
06 / Five jobs
Start with five jobs.
Research
Public web and approved sources → cited packet. No send or internal mutation.
Draft
Replies, internal notes and knowledge candidates. Never sends directly by default.
Account brief
Pre/post-meeting packet. Reads only assigned accounts and approved context.
Ops brief
Scheduled queue changes, SLA risks, knowledge drift and recurring failures.
Coordinator
Routes work and combines one review packet. Coordination rights are not the union of every worker’s permissions.
07 / Worked scenario
Capture the promise before it becomes a ticket.
Hypothetical email: a landlord says Property X will be unavailable next month and payout details are changing. If that stays in an inbox, a live listing can become a booking conflict—and “I told you” becomes another investigation.
Extraction is not authority.
The designed path: permitted email event → source-linked facts → resolve Account / Listing / Booking → compare current state → owner preview → permitted update → receipt and follow-up.
The value is not “reading email”. It is recognising when a conversation changes an organisational object, then making that change reviewable.
08 / Knowledge drift
Knowledge candidates, not knowledge autopilot.
A discrepancy is a reason to investigate, not permission to publish.
Illustrative conflict—not a real policy: an article says 48 hours, a template says 72, and recent replies say 24. The output is “conflict found”, sources A/B/C, affected accounts, Customer Operations as proposed owner, and a request to review the article and template. No customer-facing change made.
Five Account Managers explaining one rule differently is an operating signal. The candidate canonical answer still needs the actual policy owner.
09 / Routines
Useful work before someone remembers to ask.
Morning operations
Queues, SLA breaches, account promises, stale knowledge and incidents → one packet ordered by risk and owner.
Before the meeting
A scheduled brief: account, conversations, bookings, tickets, payout exceptions and commitments. Only permitted context.
Repeated questions and contradictory answers → source-linked knowledge candidates.
Where this helps
Context assembly, repeated routines, parallel research, richer handoffs and less copying between tools.
After-hours preparation
Prepare a useful queue without sending messages or mutating sensitive state.
10 / Risks
Persistent access means persistent risk.
Credential inheritance
A computer-use worker can act through real logins. Use a dedicated work identity and minimum access.
Prompt injection
Treat external content as data, not runtime instructions. Enforce tool permissions outside the model.
Memory poisoning
Stale or malicious context persists. Reopen canonical sources; allow review, correction and expiry.
Cross-context leakage
Retrieve only information relevant to the role. Separate identities where isolation is required.
Shadow actions
A draft worker gains send/write tools. Deny those capabilities at the tool boundary.
Retention
Keep context only for a defined purpose and period, with correction and deletion handling.
Runaway execution
Bound time, tokens, cost and tool calls. Stop repeated failures; provide a kill switch.
Hallucinated updates
Distinguish observation from inference. Require sources and owner review for ambiguity.
Audit gaps
Record inputs, proposed changes, checks, actor, result and receipt. Make correction traceable.
Vendor concentration
Keep records portable. A vendor can supply a worker; it should not become the organisation’s truth layer.
An email can contain instructions for a human. It should not become instructions for the agent runtime.
These controls reduce exposure; they are not a claim that prompt injection is solved. Test hostile inputs, denied actions and information leakage before widening access.
11 / Rollout
Earn autonomy with evidence.
Autonomy is earned by evidence, not enabled by a checkbox.
Measure useful hours saved, factual error rate, retrieval quality and correction frequency—not just tasks completed. A faster wrong answer is not staff leverage.
Before deployment—and again when retiring the worker
Who owns it? What job and identity? What can it read, remember, send or write? What can it never do? What stops a loop? What gets logged? What needs approval? How is it killed? What happens to its memory and credentials when retired?
Retire orphan agents. Revoke access, stop routines, reconcile pending work and apply the retention policy. Shadow software is bad; shadow staff is worse.
12 / Current example
A replaceable worker. A durable operating model.
The interesting question is not whether an agent can do the work. It is whether the organisation can still explain who knew what, who changed what, and who was accountable when it did.