Taskstreamer versus agent platform native controls
Which is reasonable, and it is also the whole problem. Your accountability question spans every provider you use, and every one of them stops at its own edge.
The bottom line
Every serious agent platform now ships governance features: permissions, approval steps, traces, audit logs, guardrails, evaluation. They are often well built, and if you run everything on one platform they will take you a long way.
The boundary is drawn around the vendor, not around your organisation. Agents on another platform are outside it. Agents a developer spun up in an IDE are outside it. Human work is outside it, which means the moment a person and an agent touch the same piece of work, the record splits in two and somebody has to staple it back together.
Nobody in your organisation has an AI-vendor-shaped accountability problem. They have a work-shaped one.
The unit of governance should be the work, not the vendor that happened to execute it.
At a glance
| Question | Agent platform native controls | Conductor |
|---|---|---|
| Which models can you use? | The vendor's, and whatever they choose to host | Yours. Any provider, or self-hosted |
| What happens when you add a second provider? | A second set of controls, a second log, a second thing to reconcile | Nothing. Same threads, same rules, same record |
| Where does human work live? | Elsewhere, in your issue tracker | The same record, under the same rules |
| Who wrote the rules being enforced? | You configure them inside the vendor's model of the world | Read from your ERP and payment platform, ratified by a named human, with the source recorded |
| What audits the audit trail? | The platform that produced it | A separate component with read-only access, checking the chain against the guarantees |
| What does leaving cost? | The agents, the controls and the history are the vendor's shape | Swap the model. The record and the rules stay yours |
| What is the unit of governance? | The vendor's agents | The work itself, human and AI |
The structural point
Shadow usage is not a policy failure, it is what happens when capable tools are one click away. Any control that only sees one vendor's agents will always be reporting on a subset, and will never be able to tell you the size of the part it cannot see.
An approval threshold should not depend on whether the thing approaching it is a human or a model. When governance lives inside an AI platform, that is structurally impossible, because people do not work inside it.
A platform's logs are produced by the platform, verified by the platform, and presented by the platform. That is fine until the question is adversarial. A system that audits itself audits nothing.
Model capability and pricing are moving faster than any governance programme can re-approve. If your controls, your history and your evidence are shaped by one vendor, switching provider means rebuilding the thing that took the longest to get signed off. Bringing your own models keeps that decision cheap.
Where each one wins
You are on one provider, deliberately, and expect to stay there.
The agents produce drafts and suggestions rather than touching systems of record, so the consequence of an unreviewed output is a wasted hour.
The people reviewing the output are the people who prompted it, and nobody outside that loop needs to answer for it.
More than one provider is in play, or you want the freedom to change your mind about that.
An agent can reach something irreversible: a payment, a record, a pipeline, a customer.
Someone outside the team has to be able to say what was produced, on what basis, and that the organisation stands behind it.
What we do not claim
The full list is published. Read the limits.
Any provider, or self-hosted. EU-built and EU-hosted, with your data staying in your boundary and our IP staying in ours.