Bring your Claude and Cursor coding agents into Port

Why we built it

Ask a platform engineer how many AI agents run in their org today and you get a shrug, not a number. Developers spin agents up wherever they happen to be working: one in a coding assistant for a one-off task, another wired into a cloud console, a third built for code review. Nobody writes any of it down, and nobody owns the list. Agents created ad hoc, live wherever they were spun up, and carry no shared record of who owns them, what data they can touch, or what they are allowed to do. That is shadow IT, reproduced for AI, and it is structurally worse: an autonomous agent can invoke actions, read sensitive data, and trigger deployments on its own, so a misconfigured one carries a bigger blast radius than a misconfigured service ever did.

Governance is only half the problem. An agent stuck behind its own provider's console cannot take part in the business workflows a team already runs. Teams want their Claude and Cursor agents to act as one more step in those workflows, not a separate system they have to break out to reach.

And once agents are cataloged and wired into workflows, the next question follows naturally: how does a team get a new one without a trip to the console every time. Port already answers that question for services and cloud resources. A platform engineer defines a template once, and a developer requests from it in minutes. Agents deserve the same golden path.

The market read the same signal. In the past few months, GCP shipped an Agent Registry for Gemini Enterprise, Notion added agent orchestration, and Databricks launched a meta-harness called Omnigent. Every platform is racing to answer the same question: who governs the agents, who can build them, and how do they plug into the automation that already runs the org.

{{from_manual_to_autonomous_engineering}}

What changed

Port now ships two new integrations. Claude Managed Agents and Cursor Cloud Agents. Together they open up three capabilities.

Catalog your agents

Install either integration and your agents land straight in the Context Lake. Claude Managed Agents brings in your Anthropic agents, environments, sessions, vaults, and memory stores. Cursor Cloud Agents brings in your Cursor cloud agents and their runs. Every agent that already exists in either account shows up automatically, owned, searchable, and auditable, even the ones nobody on the platform team built.

Create agents as self-service

A platform engineer defines a governed template once: system prompt, the tools allowed, the resource scope, and an approval gate if the template requires one. A developer then requests from that template in minutes instead of filing a ticket. The agent lands in the catalog as a first-class entity the moment it is created, so the next developer who needs something similar finds it and reuses it instead of building a fourth version of the same agent.

Trigger agents as part of agentic workflows

The Create Agent and Trigger Agent nodes work the same way whether the agent behind them is a Claude Managed Agent or a Cursor Cloud Agent. Define the agent once, then invoke it, or send a follow-up prompt to an agent session already in progress, from any Port workflow. The workflow can fire on a pull request, a scorecard change, or a manual click, the same way it calls any other integration action.

Example use cases

Governed self-service creation. A platform engineer builds a template that fixes the system prompt, scopes the MCP servers to GitHub and internal docs, and requires approval before activation. A developer fills out a form, picks a repo, and gets an approved, audited agent back in minutes, instead of the manual, one-off setup most teams are still doing today.

Automated PR review. A Claude agent evaluates a pull request's risk based on the code changed, test coverage, and how critical the affected service is in Port's catalog, a property already on the service entity. It assigns reviewers by risk tier, comments with its reasoning, and requests review automatically, so risk-based routing runs without a human triaging every PR by hand.

The scorecard-to-fix loop. A service's scorecard fails a check. Port triggers a Claude agent session and injects the failing check, the service, the owning team, and the code location directly, all pulled from the catalog Port already maintains. The agent does not spend its first five turns figuring out what Port already knows. It starts fixing the code and opens a PR; when the PR merges, the scorecard recovers. This is the sharpest answer we have to "why route an agent through Port instead of invoking it directly": Port hands the agent a session that already has context, not a blank one.

How to get access

With admin privileges, install both integrations straight from Port's Builder screen:

• Go to Builder, then Data Sources
• Under AI Agents, choose Claude Managed Agents or Cursor Cloud Agents, depending on where your agents run
• Enter the credentials that provider needs
• Your existing agents, environments, and sessions sync into the catalog within minutes

From there, the Create Agent and Trigger Agent nodes are ready to use in any workflow.

Summary

Port is becoming the registry and orchestration layer for AI agents the same way it became the developer portal for services: the agent runs wherever you deployed it, in Claude or in Cursor, and Port owns the discovery, the governance, and the invocation layer above it. You get one catalog for every agent in the org, a self-service way to create governed ones, and a way to invoke them from the same workflows you already run for everything else.

Learn more on our docs, public demo, or share your feedback on our public roadmap.

{{from_manual_to_autonomous_engineering}}