Who is supposed to build agent access for software you do not own.
That question keeps surfacing in the threads. The plainest version said it outright. Structured access is ideal, but you do not own the other side. Most vendors will never rebuild their products for your agent. That gap is the reason HIVE exists.
Now two asks, and they are different asks.
First, design partners. Teams with a real workflow they would hand to an agent today if access, permissions, and approvals were handled. You set the priority. We build toward it.
Second, MCP evaluation research. If you run MCP servers in production, we are scoping how to test whether a server is reliable and safe. Load behavior. Response quality. Permission boundaries. Failure modes. Researching this. Nothing to sell yet.
Reply or DM if either one is you. Tell us which workflow you would hand over first.
Top comments (6)
Your distinction between the two asks is clear, and the design partner idea stands out to me. A real workflow handed over with permissions and approvals handled first feels like the right test, rather than starting with a polished demo.
yeah, we agree — permissions and approvals first, on a real workflow, beats a polished demo. what workflow would you hand over first?
I would hand over a client approval workflow first, for example a design revision that needs a named approver before it moves forward. That tests permissions, audit trail and rollback in one real case, and it shows quickly whether the tool fits how a team actually works.
that is exactly the kind of workflow we had in mind — one named approver, one clear decision, and the permission boundary is obvious. if we set this up as a design partner run, what would you want the agent to do before it reaches the approver?
Before it reaches the approver, I would want the agent to pull the full context together first: the current version of the file, what changed since the last approval, and any client comments already attached. Then it should summarise the decision in plain language, flag anything that looks risky or outside the agreed scope, and only then send it to the named approver with one clear choice, approve or request changes. That way the approver is deciding, not digging through files. Happy to test that flow on a real design revision with you if a short trial helps.
yeah, that's exactly it — the approver should only ever see a decision once the context is already pulled together. what would you want in that bundle before it lands with them?