The hard part of a self-service agent platform isn't the agents

The demo that gets people leaning in is always the same. Someone who has never written a line of Python types one sentence, "an agent that triages incoming support tickets and flags the urgent ones," clicks through a few screens, and a few minutes later there's a real agent answering in a chat window. No ticket filed to engineering. No sprint. Just a working assistant that wasn't there at lunch.

I built that demo. It's part of AgentHive, a self-service platform we run at JFrog that lets anyone in the company create, govern, and ship production AI agents without code.

The wizard works. People like it. And it was the easy part. The agents were never the hard problem. Everything wrapped around them was.

Here's the Thing

• Gartner expects 40% of enterprise apps to ship task-specific AI agents by the end of 2026, up from under 5% a year earlier (Gartner, 2025). Generating an agent is basically a commodity now.
• The hard part is everything around the agent: a catalog so people can find it, permissions so the right people can use it, a way to reach it where they already work, reusable skills and knowledge, and a gate so nothing hits production unreviewed.
• McKinsey's 2026 AI trust survey (around 500 organizations) found only about a third report a governance maturity of level 3 or higher for the agentic era, even as they push autonomous agents into production (McKinsey, 2026).

Generating the agent is the commodity part

The wizard is five steps: describe the purpose in plain English, pick a model, attach tools, connect a knowledge base, review and deploy. Behind it, an LLM writes Google ADK Python, the platform validates it, and it deploys to Vertex AI Agent Engine with managed sessions and memory. It reads like magic in a demo. Under the hood it's codegen with good guardrails, and codegen got good.

That's exactly why a no-code agent builder isn't a moat. Gartner counts thousands of "agentic AI" vendors and figures only about 130 are doing something real, the rest "agent washing" old chatbots and RPA with a new label (Gartner, 2025). When the builder is easy, everyone ships one. So where does the hard part actually hide?

It hides in everything the demo skips. The agent your colleague built last week is worth nothing if you can't find it, can't reach it, and can't trust that someone checked it. That's the platform. The wizard is just the front door to it.

A catalog, so agents don't die in silos

The first hard part is visibility. AgentHive has a catalog, and the catalog shows every agent you're allowed to see, not just the ones you made. Searchable grid, status filters, the creator's name on each card. The whole point is that an agent built in one team doesn't vanish into that team. You can't govern what you can't see, and you can't reuse it either.

Visibility is a permission, though, not a free-for-all. Sharing runs through an access model: you grant an agent to a person, a group, or the whole org, as a viewer or an editor. Grant it to everyone and it's an org-wide agent anyone can open and talk to. Leave it private and it's genuinely invisible: an agent you're not cleared for doesn't show up at all, not even as a locked door you can see but can't open. So "no silos" is the default posture, but you still decide who sees what.

Once you can see an agent, you can talk to it. Open any agent you have access to and start a chat, with multiple sessions and history, and your conversations stay private to you even when the agent is shared. The catalog isn't a registry you read. It's a place you actually use the things other people built.

The other front door is Slack

A catalog people have to visit is a catalog people forget. So the second front door is Slack, and it's a real one. AgentHive runs as a Slack app: mention it in a channel or DM it, and your message gets routed to a hive agent, run through the same path as the web chat, and answered back in the thread, with live "thinking" and "calling that tool" status while it works.

The part I like is that you're not stuck with one bot. You can reach any deployed agent you're permissioned for. Pin an agent to a channel, name it in your message, or pick from a list of everything you can access, and the conversation continues in that thread with its own memory. Same agent, same permissions, same sessions as the web. Just reachable from where the work already happens. (There's no slash command yet, it's mention, DM, and the picker.)

This sounds like a convenience feature. It's actually an adoption feature. An agent nobody can reach without opening another tab is an agent that gets used twice and abandoned. Meeting people in Slack is how an internal agent stops being a demo and starts being a habit.

Capability you build once, not once per agent

Here's the part the "type a sentence, get an agent" pitch hides: the valuable agents lean on capability you don't want to rebuild every time. AgentHive treats that capability as shared inventory.

Skills are a first-class thing, not a prompt trick. A skill is a versioned bundle you attach to agents, up to twenty each, with draft and published versions, and a published version is frozen so nothing shifts under you. You can ask the platform to draft one from a description, then request to share it across the org, which an admin approves. Build the "how we format a release note" skill once, and every agent that needs it gets the same one.

Sharing a skill is one thing. Trusting one is another. A skill is just instructions and files, which means a bad one carries the same risk as a bad package: poisoned instructions, or a quiet grab for more access than it should have. So skills don't only live inside AgentHive, they're governed through the JFrog Agent Skills Registry, the same system of record JFrog keeps for MCP servers, models, and other agent assets. A skill gets scanned and signed when it's published and pulled only if it passed, so you can finally answer the questions that usually don't have one: who wrote this, what version is it, and did anything flag it as malicious. Because the registry is vendor-neutral, that record doesn't vanish the day you swap coding agents, the way it would if your skills lived in one tool's marketplace.

Tools work the same way, and the tool builder is genuinely no-code. Describe what the tool should do, and the platform generates the Python, the input and output schema, and the dependencies, then lets you test it in a sandbox before it goes through approval. Approved tools land in a shared library instead of getting welded to a single agent. That's on top of built-in tools and MCP servers you connect with your own OAuth.

Knowledge is close to one step. Point an agent at a Google Drive folder, or drag in files, and the platform builds a real Vertex AI RAG corpus and keeps it synced daily or weekly. One corpus attaches to many agents, and answers come back with source citations that resolve to the actual document. Nobody's writing a chunking pipeline.

Automations close the loop. Put an agent on a schedule or a polling interval, dry-run it first so you're not testing in production, and watch its run history. Then publish it: other people can discover it, subscribe with their own schedule, or clone it into their own. Capability someone built once becomes something the whole org can pick up.

Agents that talk to other agents

The last piece is interop, and it's where this stops being a builder and starts being a hive. Two flavors, and they're different on purpose.

Inside the platform, every agent can see and delegate to its peers. Each one gets a way to list the other agents it's allowed to use and hand a task to one of them, with a depth cap so a chain of delegations can't recurse into the weekend. That's how you avoid the one-giant-agent trap: a generalist routes to a specialist instead of trying to be it.

Across the wire, AgentHive speaks A2A, the open agent-to-agent protocol. Every agent publishes an agent card at a well-known URL that lists its skills and how to call it, secured with a bearer key. Your agent can call a remote A2A agent (paste its card URL in the builder), and outside systems can call yours. It's synchronous and single-shot today, no cross-org multi-turn approvals yet, so I'm not going to oversell it. But the bones are there, and they're the open-standard ones, not a private protocol I'd have to apologize for later.

The part no demo shows: the approval gate

Now the unglamorous center of the whole thing. Everything above, the catalog, Slack, shared skills, delegation, is only safe to hand to non-developers because nothing reaches production by accident. Every agent moves through real states: Draft, Pending Review, Approved, Deploying, Deployed, Disabled. You can't skip a step. An agent reaches production because it cleared a gate, not because someone clicked deploy. Building a state machine for sign-offs is nobody's idea of exciting AI work, which is probably why it's the first thing teams skip.

The gate is a dual-team review. The AI team checks the purpose, the model, and the tool configuration. The Security team checks tool permissions and what data the thing can reach. Both have to approve. A rejection comes back with feedback and the agent drops to Draft to be fixed. Around it sits the rest of the boring surface area that makes the fun stuff survivable: an audit log of every action, and identity wired into Okta with SCIM so accounts provision and deprovision themselves. That last one matters more than it sounds, a Cloud Security Alliance survey found only 23% of organizations have a formal strategy for agent identity (Strata, 2026). Most are improvising.

There's a subtler way to get this wrong, and Gartner just named it. It expects a large share of enterprises to demote or decommission their autonomous agents by 2027, after governance gaps surface in production incidents, and it pins the blame on uniform governance: the reflex to gate every agent the same way, which throttles the harmless ones and under-watches the dangerous ones (Gartner, 2026). That trap is exactly what the gate is shaped to dodge. Every agent goes through the same lifecycle, but the weight of the review scales with what the agent can actually do. An agent that only reads a knowledge base gives Security very little to weigh. The moment it picks up tools, the review becomes the trust boundary Gartner is talking about: which tools, what permissions, what data it can reach. And an agent that runs on its own, on a schedule or a poll, gets the heavier treatment: a dry-run before it touches anything real, a run history you can watch, and a delegation cap so an autonomous chain can't wander off. Same gate, different weight, set by how far the agent can go without a human in the loop.

Underneath all of that is the framing that finally made it click, from McKinsey's read on what the mature teams do differently: they treat governance as a product, not a process. Instead of a policy doc and a quarterly review, they build the controls into the platform itself, the way a sane org built security into its DevSecOps pipeline instead of bolting it on at the end. That's not an accident at JFrog, where "shift it left and make it part of the pipeline" is the water you swim in. The approval queue is a pipeline stage, not a meeting.

I made a version of this argument about Claude Code hooks: guardrails belong somewhere deterministic, because a block has to actually block, not politely suggest. Same instinct here. A policy that says "get security to review your agent" is a request people route around when they're busy. A lifecycle that refuses to deploy an unapproved agent is not.

This is also why I won't throw adoption numbers at you. I could tell you how many agents are live or how fast something gets approved, and you'd have no way to check it, which makes it worth roughly nothing in a post like this. The honest claim is narrower: the governance layer is the part that was hard to build and the part I'd defend. The wizard was a couple of good weekends.

Why we built it instead of buying one

The question I get most is why we built this at all. The products exist. So why not buy?

Because the builder was the commodity, and it's the only part you can cleanly buy. Gartner just ran its first quadrant for no-code agent builders, Microsoft, Google and AWS out front (Gartner, 2026). Google's Gemini Enterprise or Salesforce's Agentforce will spin one up faster than the wizard I described. But the moment you ask for the rest of the platform, the catalog and its permissions, the Slack door, shared skills and tools, the RAG sync, the approval gate, you stop buying a product and start buying a vendor's gravity. Gemini Enterprise assumes you're standing in Google's stack. Agentforce assumes Salesforce.

Governance is where it got personal. The closest thing to what I wanted is AWS, which added an Agent Registry to AgentCore that genuinely reaches across vendors, cataloging agents, tools, and skills behind an approval workflow (AWS, 2026). Right idea, real product. It's also a developer's tool, reached through an API, a CLI, an IAM policy. That's a fine fit when the people building your agents are engineers. Ours aren't. The whole premise of AgentHive is the colleague who has never written a line of Python, and you can't hand that person a registry they drive from a terminal and call it self-service. The neutral governance exists. It just sits behind a keyboard the people building these agents don't touch.

And even past the audience problem, that registry still lives in one vendor's cloud, which is the real disqualifier for a company like JFrog, whose whole job is being the vendor-neutral place your assets stay no matter whose tools you rotate through. We run AgentHive on Google's Vertex AI and still didn't buy Google's agent platform: we wanted the runtime, not the system of record. Buying that from a single agent vendor would undercut the thing we sell. So the math was lopsided: the easy part was buyable, the hard part buyable only in pieces, and the piece I cared about most, governance that survives a vendor swap, wasn't for sale in a form I could use.

I'm not going to tell you to build. If you live inside one ecosystem, buy into it, just make sure it actually does in production what the keynote promised (I'm looking at you, Gemini Enterprise). But agents are about to be everywhere, and only 21% of companies have a mature way to govern them yet (Deloitte, 2026), so whoever's control plane all those agents end up living in is a decision you make once and regret slowly. Build when neutrality is the point, not a preference. For us it was the point.

What I'd tell you before you build one

If you're about to build an internal agent platform, here's the part I wish someone had told me. The builder will take a fraction of the time you budget for it. Codegen plus a model picker plus a deploy call is a known quantity. The calendar goes to the surface nobody screenshots: the catalog and its permission model, the Slack front door, the shared skills and tools, the RAG sync, the approval lifecycle, the audit trail, identity. That's where the work is, and it's where the platform earns the right to exist inside a real company.

And stay honest about what's still rough. A2A is synchronous-only for now. Observability is opt-in rather than always-on. The Slack status niceties need the right Slack plan or they quietly degrade. None of that is a crisis, it's just the gap between a thing that demos and a thing you'd stake a production incident review on. Pretending the gap is closed is how a promising agent platform turns into a postmortem.

Frequently asked questions

What is AgentHive?

A self-service platform built at JFrog that lets non-developers create, govern, and deploy production AI agents without code. It generates Google ADK Python, deploys to Vertex AI Agent Engine, and wraps every agent in a catalog, a permission model, Slack access, shared skills and tools, and a dual-team approval gate.

Isn't the no-code builder the hard part?

No, and that's the whole argument. Generating an agent is mostly solved by codegen and a good model. The hard, slow work is everything around it: discovery, permissions, reuse, interop, and governance.

Why build AgentHive instead of buying an off-the-shelf platform?

Because no vendor bundles the whole shape: a no-code builder plus a catalog, permissions, Slack access, shared skills and tools, RAG, and a dual-team approval gate. The closest cross-vendor governance, AWS's Agent Registry, is built for developers, not the non-coders AgentHive is for. And buying governance from one agent vendor would undercut the neutral system of record JFrog exists to be.

Can people across the org use agents other people built?

Yes, if they're permitted. Agents are shared through an access model (grant to a user, a group, or everyone, as viewer or editor), and a shared agent can be opened and chatted with from the web catalog or from Slack. Restricted agents are invisible, so visibility you control is the point.

How do you reach an agent from Slack?

Mention the AgentHive app in a channel or send it a DM, and your message routes to a hive agent and gets answered in the thread, with live status while it works. You can reach any deployed agent you have access to, by pinning it to a channel, naming it, or picking from a list. There's no slash command yet.

What's the stack?

React and TypeScript on the front end, FastAPI and PostgreSQL on the back, Google ADK with Vertex AI Agent Engine and RAG Engine for the runtime, Claude and Gemini as the models, MCP for tools, A2A for agent-to-agent, and Okta with SCIM for identity. Observability runs through Langfuse when it's on.

Where I landed

I came into this thinking the clever part would be the code generation, the bit that turns a sentence into a running agent. That part was fun, and it was fast. The part I'm actually proud of is the stuff with no screenshot value: the catalog that kills silos, the Slack door that gets agents used, the shared skills, and the approval queue that nobody wants to build.

If you're evaluating or building one of these, watch where the demo spends its time, then ask the questions it skips. Where do these agents live? Who can reach them? What did they build once and reuse? And who signed off before this touched production? If the answers are a shrug, you've been shown the easy part.