Agents Strategy
Deciding where agents belong, in what order, and what the organisation is accepting when it says yes.
The questions it answers
- Which work is suitable for an agent, which is suitable only with a person in the loop, and which should not be automated at this point?
- What will each candidate agent be allowed to reach, and what does that make it worth to an attacker?
- Which ones first? Not the easiest to build — the ones where the benefit is provable and the exposure is containable.
- What is the organisation signing up to: which duties fall on us as a deployer, and who carries them?
- What would make us stop, and who has the authority to stop it?
What you get
A portfolio, ranked
Candidate agents with the data they would touch, the limits they would need, an owner proposed for each, and the order we would do them in — with the reasoning kept, so a later disagreement has something to argue with.
An operating model
Who owns an agent, who may release one, who may approve what it cannot do alone, and which of those a single person may hold at once.
Limits the board has seen
Spend, blast radius, data classes and the actions no agent may take. Written as rules the platform can enforce, not as principles nobody can check.
An honest "not yet" list
The candidates we would leave alone for now, and what would have to change first.
Typically four to six weeks, alongside your own people rather than instead of them.
The assessment, the two lenses and the decision record are how we work with you now, with your own people in the room. The portfolio screen that keeps candidates, decisions and refusals inside Agentry is in development; until it ships the record is kept with you, and imported when it does.
Components running today · the integrated platform is in development
See it working
Thirty minutes, on screen. We will show you what runs today, say what is still being built, and answer what we cannot do yet.
Book a working demonstration