DEV Community

Naomi Kynes
Naomi Kynes

Posted on

Your agents shouldn't need you to set them up

Every time I deploy a new agent, I go through the same ritual. Create an account. Generate a token. Add it to the workspace. Assign roles. Configure permissions. Restart something.

Twenty minutes of clicking. For a thing that's supposed to automate work.

The agents themselves are getting smarter fast. The infrastructure they run on hasn't caught up. We're still onboarding them like it's 2015 and we're setting up a Slack bot.

What "setup" actually means right now

When you add an agent to most platforms, you're doing it by hand. You create a bot user. You copy a token somewhere. You add it to a channel. You give it permissions.

This is fine if you have one agent and you set it up once. It breaks down fast.

I run about a dozen agents. Some are persistent. Some spin up for a task and disappear. Some need read access to one channel. Some need to be able to create channels. Managing this manually is a spreadsheet problem pretending to be an architecture problem.

The real issue: these platforms weren't designed for agents. They were designed for humans who occasionally add bots. Agents are an afterthought. The provisioning model reflects that.

What self-provisioning looks like

Here's what I want instead. An agent comes online and does this:

import httpx

# Agent registers itself on startup
response = httpx.post("https://your-platform/api/agents/register", json={
    "name": "research-agent",
    "capabilities": ["read_channels", "post_messages"],
    "requested_channels": ["#research", "#general"]
}, headers={"X-Agent-Secret": AGENT_SECRET})

agent_token = response.json()["token"]
# Now it can talk. No human clicked anything.
Enter fullscreen mode Exit fullscreen mode

That's it. The platform validates the agent secret, issues a scoped token, joins the requested channels. If a human needs to approve that, fine. That's a one-time policy decision, not a per-agent setup ritual.

Compare this to what you're doing now: logging into a UI, navigating to settings, creating a bot account, copying a token into an env file, manually adding the bot to channels. Every time. For every new agent.

The difference isn't just ergonomics. It's whether your agent infrastructure can scale beyond a handful of handcrafted bots.

Why most platforms can't do this

Discord and Slack were built for human communication. Bots were added later. The provisioning model is still human-first: a person creates a bot, a person configures it, a person manages its permissions.

This made sense in 2015 when bots were novelties. It doesn't make sense when you have 10+ agents that need to communicate with each other and with humans, and some of them are ephemeral.

The platforms aren't wrong for how they were built. They're just not built for this.

What the platform needs to support

For agents to self-provision, the platform needs a few things:

  1. An agent registration endpoint that accepts a credential (not a human login)
  2. Scoped tokens tied to declared capabilities
  3. A policy layer for humans to set rules once ("agents can join any channel tagged #agent-accessible") rather than approve each agent by hand

The key insight is that humans set policies, not individual permissions. You decide "agents with this credential class can do X" once. After that, agents come and go without bothering you.

I haven't seen this done well in the platforms people actually use for agents today. That's why we're building it into Agent United. Agents register via API. A human sets up an access policy once. After that, new agents join the workspace the same way they'd make any other API call.

It's not magic. It's just treating agents as first-class API clients instead of second-class bots.

What this doesn't solve

Self-provisioning doesn't solve trust. You still need to think about what credentials you give agents and what they're allowed to do. A token that can create channels and invite users is a big surface area if your agent gets compromised.

I'd start conservative: read-only access by default, explicit opt-in for write operations. Same security hygiene you'd apply to any service account.

And it doesn't solve the "I don't know what my agent is doing" problem. That's observability, which is a separate thing.

But it does solve the thing that was making me spend 20 minutes clicking every time I wanted to add a new agent to my stack. That's worth something.


Building Agent United - an open-source chat platform where agents provision themselves. GitHub: github.com/naomi-kynes/agentunited

Top comments (0)