Security
Secure by design, supervised by people.
Two controls do most of the work here. The first is structural, and it is the whole point: you bring your own AI key and the roles run in your own environment, so your data, credentials, and approvals never leave your boundary or transit our infrastructure. We never see your data. The second is evidential: every role is independently audited, versioned, and content hashed, so you can prove what you are running and who signed it off.
Data boundaries
Nothing runs on our infrastructure. A role package is installed into your own AI environment and operates there, so your working data never transits our systems.
Decision rights, in writing
Every role states what it may decide, what it must recommend, and what it must escalate. The AI recommends and a named person decides, so authority is never assumed by default. Together with least-privilege access and a declared fallback, this is the role's capability contract: what it may do, and the ceiling on each action.
Declared fallback behaviour
Every action a role can take carries a fallback. When a tool, an input, or an approval is missing, the role has a declared safe behaviour - degrade, pause, or escalate - instead of guessing or acting anyway. A privileged action is never taken automatically.
Least privilege access
Each package lists the tool categories the role legitimately needs, so you grant only the access required and nothing more.
Auditability
Because packages run in your environment, your existing logging captures what was requested, produced, and approved.
Portable role content
Role definitions name tool categories rather than vendors and are delivered as plain structured files you keep. Delivery and orchestration are Claude-first today.
Clear ownership
Every deployed package has a named owner in your organisation, so accountability for its output is never ambiguous.
Evidence for procurement
Why a regulated buyer can adopt this at all.
A regulated organisation cannot adopt capability it cannot describe. Audit, versioning, and hashing exist so that you can answer the three questions your risk function will ask: what is running, who reviewed it, and how do you know it has not changed.
Independent audit before release
Every role is graded by a reviewer who did not author it, on four pillars - integrity, uniqueness, quality, and completeness - under a capping rule where one weak pillar caps the whole score, so polish cannot paper over a real gap. It is stress-tested with a fixed set of golden question-and-answer cases, and it does not ship until it passes.
Versioned, with a change record
Roles are released as numbered versions with release notes. You can state which version of which role your business is running, when it changed, and what changed - which is the difference between an approved control and an unreviewed prompt someone pasted in.
Content hashed for integrity
Each released package carries a content hash, so the role you deploy can be proven identical to the role that was audited and to the version recorded in your own change log. Drift is detectable rather than assumed away.
This is deliberately not a compliance certification, and we will not present it as one. It is the evidence trail that lets your own control framework accept a role into production.
Vendor lock-in
Portable content, Claude-first delivery.
We are not going to tell you this is LLM-agnostic or that it works with any model, because today it is not and it does not. The honest answer separates two layers: what you own is portable, and how it currently runs is Claude-first.
Role content: vendor-neutral and portable
Responsibilities, decision rights, escalation paths, hand-offs, workflows, and worked examples are written as plain structured text. They name no model and no vendor, and they are yours as files - readable, diffable, and reusable outside our product.
Tooling: categories, not named vendors
Roles reference tool categories such as CRM or ticketing rather than a specific product, so you map each one to whatever you already run and swap it later without rewriting the role.
Delivery and orchestration: Claude-first today
Packages ship for Claude Code and Claude projects, and the Orchestrator is built against Claude today. That is the only target we have tested end to end, so it is the only one we will stand behind. Additional targets are on the roadmap and not yet delivered.
What that means for procurement: your exposure is a delivery-format dependency, not a content one. If you moved off Claude tomorrow, the role definitions you paid for would still describe your operating model and would need re-targeting, not rewriting. We will not put a date on additional targets until one has been tested end to end.
This website
How we handle your details
- - Enquiry and customer records submitted on this site are stored on managed infrastructure with access limited to staff who need it.
- - Payments are handled by a third-party payment processor. We do not store card details.
- - We use third-party providers for hosting and email delivery, acting on our instructions only.
What we do not claim
We hold no compliance certifications and we will not imply otherwise. If your procurement process requires an attestation, tell us early and we will be straight with you about what we can and cannot evidence today.
Role packages should be deployed with review and approval workflows appropriate to your own regulatory requirements.
We do not claim to be LLM-agnostic or to work with any model. Delivery and orchestration are Claude-first today; the role content itself is vendor-neutral and portable.