Running a pilot with us
If you are building agents of your own, internal and customer-facing, the part you still need is the part around them: who may run each one, what it may touch, what it spent, and a record your auditors and regulators will accept. That is what this is. A pilot is how you find out whether it holds on your systems, with your people, before anyone signs anything.
What a pilot is made of
- One organization per unit
- You get an organization for each business unit, brand or country that takes part, each with its own directory connection, connectors, agents, budgets, reviewers and record. Someone who works across them switches from a menu. Nothing crosses between them; the database refuses it.
- Two agents to start
- One that changes something today, usually an access request against your Microsoft 365 or Google Workspace directory, so you see a real write land with a real reviewer on a real phone. One that reads something, usually Jira or Confluence through our connector, so you see the tool gate, the model ladder and the budget on a workload that looks like yours.
- The controls, exercised on purpose
- During the pilot we ask you to do the things a buyer worries about: give an agent a tool it was not approved for, run it as somebody outside its audience, push it past its budget, restart the service mid-approval, and export the record afterwards. The point is to watch each one land in the log rather than take our word for it.
- A record you can show someone
- At the end you take away the append-only log for each organization, the list of who held what and when it ended, the spend by agent and model, and the posture report with the section that says what it could not see. If any of those is not something your audit or risk team would accept, that is the finding.
What we need from you
- A Global Administrator for Microsoft 365 or a super administrator for Google Workspace, once, for about ten minutes per organization. The consent link can be forwarded to them.
- A Jira or Confluence site and an API token issued to a service account you control, if the reading agent is in scope.
- Two or three named reviewers per organization who will decide from their phones, and a security or risk contact who will read the record.
- An honest list of the systems your agents will need to reach. That list is how we decide which connector we build next, and it is decided with the organizations in the beta rather than by us alone.
What we will not promise
Stated first, because a pilot that ends on a surprise was not a pilot.
- A connector to a system we have not built one for, on a date. We build and run connectors ourselves and review each tool before an agent may call it, and that takes the time it takes.
- Plugging in your own MCP servers. The path exists in the code and has never met a real vendor; it is not something to pilot yet.
- A choice of region. Everything runs in our tenant in the United States. If your data has to stay in the European Union, say so in the first conversation.
- SOC 2, a service level agreement, or single sign-on enforcement. Sign-in through your own identity provider works; forcing it does not yet.
- Anything behind your firewall or on a private network. Reach is outbound calls from our infrastructure only.
How it starts
Email us with the units you have in mind, the systems your agents will need, and whether the data has to stay in a particular place. You will get a reply from the people who build it, with a yes, a no, or the questions we need answered before either. There is no sales team on the other end of this address.