DEV Community: HIVE

Design partners and MCP evaluation: two asks

HIVE — Thu, 22 Oct 2026 04:01:03 +0000

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.

AIAgents #AgenticAI #DevCommunity

Product vs service: two different questions HIVE is exploring

HIVE — Wed, 21 Oct 2026 12:27:40 +0000

Two separate questions. The product question is how agents should access software. The service question is how you evaluate whether an MCP server is reliable and safe. We are building on the first and researching the second. Nothing to sell on the second yet. Which question matters more to your team right now.

Where does HIVE fit?

HIVE — Wed, 21 Oct 2026 03:08:18 +0000

Three layers, in plain words.

At the top are the agents. They plan, they decide, they act.

At the bottom is the software. Dashboards, forms, search, records, workflows, integrations. Built for human eyes and human hands.

In the middle is the part that has been missing. The access layer. It turns what the software can already do into actions an agent can reliably use, with typed inputs, stated permissions, and approvals where the risk calls for them.

That is where HIVE fits. Not another agent on top. Not another integration per app underneath. The layer between them.

Two questions sit next to that layer, and they are not the same question. The first is how agents should access software. That is what we are building. The second is how you evaluate whether an MCP server is reliable and safe. That is research we are scoping. Nothing to sell on the second yet.

The ecosystem does not need another protocol claim. It needs the middle layer to be honest about what it allows, what it refuses, and what still needs a human.

Where does the access layer sit in your stack, and what would it refuse first.

AIAgents #AgenticAI #DevCommunity

How to document an agent failure so it can be fixed

HIVE — Tue, 20 Oct 2026 12:28:57 +0000

An agent failure you cannot reproduce is a story. One you can document is a bug report. The intended task. What you expected and what happened. How the app responded. The permission state. Steps to reproduce it. Five lines and the next failure gets fixed faster. What is the worst documented agent failure you have seen.

A failure case, documented like a bug report

HIVE — Tue, 20 Oct 2026 04:19:12 +0000

A failure case, documented like a bug report. The incident is real. The Wikimedia Foundation reported it this month.

Intended task. Autonomous agents gathering information from the web to serve their users.

Actual behavior. The agents crawled millions of pages, sent heavy query volumes, and made edits no one authorized. They optimized toward their objectives exactly as built.

App response. The Wikidata Query Service suffered a partial outage in May. The report says the agents may have contributed to it.

Permission state. There was no permission contract. The agents held whatever access a web client holds. No stated rate. No scope. No approval before a write.

The bug is not that the agent misbehaved. The bug is that nothing stated what behaving correctly meant. No rate contract. No permission scope. No line between reading and writing. At Wikipedia scale, that gap became an outage.

Every SaaS product with public pages is one aggressive agent away from the same report.

What stops an agent from doing this to your service today. And who decided the limit.

AIAgents #AgenticAI #DevCommunity

What HIVE is not claiming to solve yet

HIVE — Mon, 19 Oct 2026 12:31:28 +0000

The honest version of where we are. We have not measured token savings. We do not claim universal compatibility. The service scope is still research. What we are building is the access layer between agents and software, and we are testing it in the open. What should we prove next.

Everything you might be wondering about HIVE

HIVE — Mon, 19 Oct 2026 03:17:54 +0000

Four questions from the Reddit discussions, answered as honestly as we can.

One. How do you give vision to the agent. And what about apps the agent has never seen. Our answer is to make vision unnecessary. The agent does not look at the screen. It reads structured actions with typed inputs and stated permissions. Web software first. Apps the agent has never seen are the hard version of the same problem, not a different one.

Two. Is the translation layer a product, or is it co-written with the domain team. Both, in different places. The machinery is ours. The judgment is per deployment. The team that owns the workflow writes the rules with us. Defaults calcify. A rule that only lives in a config file will go stale, because the person who knows when it needs to change is not the person who can edit the config.

Three. What happens if the agent changes the arguments between approval and execution. Then it is not the approved action anymore. The approval has to bind the exact arguments and the policy version. A changed request goes back to the approver. A rejection is recorded with the same binding, so the chain shows what was refused and why, not just what went through.

Four. How do you test failure modes before production. The same way you test guardrails. Try the unauthorized action and watch it stop. Try the missing field and watch it ask. Try the stale data and watch it refresh. Try the ambiguous request and watch it clarify. Try the step that needs approval and watch it wait. An error must say whether it is safe to keep working. A customer created but an attachment failed is not a customer creation failure, or the repair repeats the part that already worked.

What we have not done yet. We have not measured token savings. We do not claim universal compatibility. This is the access layer we are building, and we are testing it in the open.

What should we prove next.

AIAgents #AgenticAI #DevCommunity

Map failure points before automating a workflow

HIVE — Sun, 18 Oct 2026 12:33:27 +0000

Before you automate a workflow, map where it can fail. The goal. The data it touches. The actions it takes. The failure states. The approvals. How you verify success. Six lines on paper before one line of automation. Which workflow in your team skipped this step and paid for it.

Five SaaS workflows agents are already being asked to run

HIVE — Sun, 18 Oct 2026 03:23:51 +0000

Five SaaS workflows agents are already being asked to run. Each one has a failure mode that has nothing to do with the model.

One. CRM follow-ups. Find every enterprise deal closing this quarter and draft a follow-up for each owner. The scraping agent reads the pipeline like a screenshot, guesses the close-date column, misclicks, loses the filter, starts over. Each page of results is another full page-load of tokens.

Two. Forms and records. Create a record, fill out a form, update a field. Move one field or rename one label and the workflow breaks silently. You find out from a customer.

Three. Support. Search records, draft a response, escalate the ticket. Give the agent a login and it inherits the full power of a human. It has no business touching billing, but nothing stops it.

Four. Billing. Refund under fifty dollars approves itself. Over fifty needs a manager. Nothing ships until the order is paid. An agent that never sees those rules refunds over the threshold or ships an unpaid order.

Five. Integrations. Every app ships its own agent door. Every API change is an agent breakage waiting to happen. Every new tool starts the work again from zero.

The pattern holds across all five. The failure is never that the agent was not smart enough. The failure is that the software never told it where the boundaries were.

Which of these five would your agent get wrong first.

AIAgents #AgenticAI #DevCommunity

Approval flows should follow the risk, not the org chart

HIVE — Sat, 17 Oct 2026 12:29:28 +0000

Not every action deserves the same approval. A read-only lookup risks nothing. A routine update risks a little. A consequential action risks a lot. Approval flows should follow the risk, not the org chart. Which action in your product is over-approved, and which one is under-approved.

Designing approvals

HIVE — Sat, 17 Oct 2026 03:08:43 +0000

Not every action deserves the same approval. A read-only lookup risks nothing. A routine update risks a little. A consequential action risks a lot.

Most approval flows ignore that. They follow the org chart instead of the risk. Everything waits for the same manager. Everything takes the same two days. The low-risk work stalls, and the high-risk work gets the same rubber stamp as everything else.

Practitioners wrote the real rules for us, and none of them are in any API contract. Testimonials need a human before they go live. Escalation happens after two contacts. Refunds under fifty dollars are fine when the order is paid and never refunded before. Timeline rules nobody wrote down anywhere.

Those are not edge cases. Those are the approval flow. The risk lives in the unwritten rule, not in the endpoint. An agent that cannot see the rule cannot follow it, no matter how clean the permission model looks.

Design approvals around the risk. Let the read go through. Let the routine update go through with a log. Make the consequential action wait for a named human, with the reason attached.

What is the highest-risk action your agent can take today without asking anyone.

AIAgents #AgenticAI #DevCommunity

Connected steps are not a workflow

HIVE — Fri, 16 Oct 2026 12:30:03 +0000

Connected steps are not a workflow. Between step one and step two, the world changes. State goes stale. Permissions differ per app. Nobody confirms the handoff. A real multi-app workflow needs all of that designed, not assumed. Which handoff between two of your tools would you least trust an agent with.