Platform Beaver: Running Port's Own SDLC on AI Agents

At Port, we build a platform for engineering teams, and since May our platform team has been running Port's own software delivery lifecycle on it. Our R&D org now files bugs, responds to incidents, reviews pull requests, and gets platform questions answered through AI agents built in Port, reached from Slack through a bot we call Platform Beaver. This post is the story of how we built that internal AI SDLC, the impact it has had, what surprised us along the way, and what it changed about how we build Port itself.

Key Takeaways

• Since May 2026, our platform team has run Port's own agentic SDLC on the platform we build, with Platform Beaver as the Slack interface to Port AI Agents.
• Making agent routing a piece of configuration in Port, instead of a line of code, is what let the setup scale across teams.
• Per-user OAuth turned out to be just as important as the agents themselves, because without real user identity, agents couldn't act with real permissions.
• Beaver now runs bug triage, incident response, PR review, alert analysis, flaky test triage, and platform Q&A in the Slack channels our teams already use, which has meant more developer self-service, fewer platform tickets, and faster incident resolution.
• Running our own SDLC on agents changed how we design Port's data model, our self-service workflows, and our MCP Gateway roadmap.

Why We Decided to Run Port's Own SDLC on the Platform We Build

Before Beaver existed, platform requests at Port were handled the way they are at most companies: in Slack threads. Someone would ping a channel, a platform engineer would eventually see it, and the back-and-forth of clarifying details, checking Port for context, and updating a ticket would happen manually. Managing those same requests directly in Port reduced some of that friction, but it introduced a different one: constant switching between the tool where the conversation happened and the tool where the work was tracked.

The goal from day one was simple: let people ask for things in the place they already are, and let the platform do the rest. But we also had a second, less obvious motivation. If we expect our customers to run agentic engineering workflows on Port, we should be running our own SDLC the same way. Platform Beaver is how we see what an agent-driven SDLC looks like in daily practice, in the channels where real incidents get triaged and real pull requests get reviewed.

How Platform Beaver Is Structured

Beaver's first version, launched in early May, was a standard Slack app with no AI involved, a thin wrapper over Port's APIs. Users @mentioned the bot with a specific command and a set of arguments, such as one command to update a request's status and another to list what was available. It worked, but every new command meant a code change, and users had to remember exact syntax. Around the same time, we shipped Ask Code, a parallel integration with Cursor's cloud agent API that let people ask coding questions in a dedicated channel and still runs alongside everything else today.

The turning point came two weeks later, when we replaced the rigid command dispatcher with natural language, backed by Port AI Agents that handle intent and action instead of a fixed set of handlers. Users stopped memorizing syntax: they mention the bot the way they'd mention a coworker, and the agent figures out what to do.

That pivot immediately raised a new problem: which agent should respond to which channel? The first answer was hardcoded into the bot itself: incident channels went to one agent, the platform team's channels went to another, and everything else fell back to a generic one. It worked, but every new channel type meant another code change and redeploy.

The fix, shipped a month later, was to stop hardcoding routing altogether. Which agent handles a channel became a setting anyone could change instead of a line of code, so adding a new channel type no longer needed a deploy. A day later, we layered in per-user identity: instead of every action running under one shared bot account, each person logs in once, and everything they do afterward is attributed to them and runs with their own permissions. A week after that, a one-command self-service flow shipped, letting any team assign an agent to their own channel in seconds, which turned what used to be a platform-team ticket into something teams handle themselves.

Natural language, configurable routing, per-user identity, and self-service setup together make up a platform in its own right: the agentic foundation our platform team provides to the rest of R&D, with Beaver as the way people reach it. The platform team owns the infrastructure, identity, and shared plugins, and each team owns its agents and the outcomes they produce. Channels, agents, and permissions are all managed through the same catalog we build for our customers.

The Three Things That Surprised Us Most

We expected the agents to be the hard part. In practice, three things surprised us more.

1. Identity mattered more than intelligence. Before per-user OAuth, every action Beaver took ran under a single service account. That meant we couldn't tell which person had triggered a change, and users couldn't touch anything gated by their own Port permissions. At first we treated OAuth as a nice-to-have for attribution. It turned out to be the thing that unlocked everything else, including access to Port's MCP Gateway, because an agent without a real identity is an agent nobody trusts with real actions.
2. The interface change mattered more than any agent improvement. Moving from slash commands to natural language did more for adoption than the prompt tuning we did afterward. We'd assumed the hard problem was making agents smarter. It turned out the hard problem was making the bot easy to talk to.
3. The "one agent per team vs. one shared agent" debate had no clean winner. We expected to land on a single answer: either every team owns its own agent, or a generic agent serves every #ask-* or #incident-* channel. Team-specific agents gave better, more tailored answers but meant duplication and uneven investment (compare #ask-fe to #ask-data). Shared agents were easier to maintain and improved for everyone at once, but produced more generic responses. We still run both models side by side, and we now think that is the right long-term setup.

Where Agents Helped Most and Where They Didn't

Agents helped most in workflows with a clear structure and a clear owner. Bug triage in #rnd-report-an-issue is a good example: the agent runs the entire triage conversation, collects repro steps, identifies likely owners, and files a structured bug report, work that used to require a human to context-switch into Port and back. Incident response is similar: agents in #incident-* channels handle initial triage, support ongoing investigation, draft RCAs, and post status updates, all in-thread, without anyone leaving Slack.

PR review agents in channels like #rnd-pr-platform-team and #rnd-pr-frontend-infra summarize changes, flag review concerns, and tag the right reviewers. These tasks are narrow enough that the agent rarely needs to ask a clarifying question. Alert analysis and flaky test triage follow the same pattern: well-scoped, catalog-aware tasks where Port's context lake (who owns what, what depends on what) supplies most of the context.

Agents underperformed mostly where the task was open-ended or where a generic prompt had to stand in for team-specific context. This is the same tension as in the design debate above: a shared agent serving many #ask-* channels gives serviceable but generic answers, and #ask-platform works best when it can also take action, not just answer. Where the task required human judgment about trade-offs, or where the "right" action depended on unwritten team context, agents still needed a human in the loop, and clarifying questions surfaced through interactive Slack modals rather than a fully autonomous decision.

What Running Platform Beaver Changed in How We Build Port

Running our own SDLC on Beaver also changed the product. Modeling Slack channels as first-class Port entities, with agent ownership as a relation instead of a config file, came directly out of watching hardcoded routing fail to scale. Per-user OAuth for agents became a pattern we now recommend broadly, not just a fix for Beaver's identity problem. Routing agent actions through workflows that already exist in Port, instead of writing a custom integration for each use case, meant RBAC and governance came with them, and it reinforced how central MCP Gateway has become to our roadmap.

The other shift is in how we frame new work. We stopped asking "should this be a bot feature?" and started asking "should this be a Port entity, a workflow, or an agent?" Treating agentic AI development as a data modeling problem as much as a prompting problem now shapes every new agent we build, for ourselves and for the platform engineers using Port everywhere else. If you're evaluating whether your own agentic impact is paying off, our advice is the same one Beaver taught us: build the smallest agent that can act with real identity and real context, and let configuration, not code, decide where it runs next.

The Impact of Running Port’s Own SDLC on AI Agents

Since we started in May, the results show up in day-to-day work for developers and for the platform team:

• More self-service. Developers resolve more of their own requests through agents and workflows instead of opening tickets, and teams outside the platform team have built tens of  agents of their own.
• Fewer platform tickets. Requests that used to wait in the DevOps queue now get handled in the channel where someone asked.
• Faster incident resolution. Incident channels get triage, investigation support, and RCA drafts from the first message, so responders start with context instead of gathering it.
• Bugs resolved automatically. About [X]% of reported bugs are now resolved by agents without anyone picking them up by hand.

The bigger change is in how the platform team spends its time. We answer fewer one-off requests and spend more of our week on the foundation that other teams build their agents on.

We're still iterating on Platform Beaver every week, and we'll keep sharing what we learn as we push it further toward an AI software factory for our own engineering org.

{{from_manual_to_autonomous_engineering}}

FAQ

What role does a software catalog play in agentic AI development?

The catalog gives agents context they can't infer from code alone: who owns a service, what it depends on, where it runs, and what changed recently. In our setup it also holds the configuration, such as which agent serves which Slack channel, and the workflows agents can trigger, so permissions and governance apply to every agent action.

Do engineering teams need to change their structure to adopt an agentic SDLC?

Teams can keep their existing structure, but ownership shifts. At Port, the platform team owns the shared foundation: routing, identity, integrations, and plugins. Each team owns its agents and the results they produce. Teams that put time into defining their agents get better answers, so an agent becomes something a team maintains, like any service it owns.

Which parts of the SDLC are best suited for AI agents?

Tasks with a clear structure and a clear owner work best. For us that means bug triage, incident triage and RCA drafts, PR summaries and reviewer assignment, alert analysis, and flaky test triage. Open-ended work, and decisions that depend on trade-offs or unwritten team context, still need a person in the loop.

How long does it take to set up an AI software factory?

It depends on the foundation you already have. We went from a standard Slack app to natural-language agents in two weeks, and to configurable routing, per-user identity, and self-service setup in about two months. Most of that time went into the foundation rather than the agents. Now a team can connect a new agent to its channel in seconds.

What are the biggest risks of running an SDLC on AI agents?

In our experience, three stand out. Agents that run under a shared service account hide who triggered a change, so every agent call should run with the user's own permissions. Shared agents give more generic answers, and one bad change affects many channels. Team-specific agents are only as good as the effort each team puts into them.

{{from_manual_to_autonomous_engineering}}