The risks of agentic chaos

How to face the top problems ahead and control your non-human workforce in the age of AI agents

August 18, 2025

Ready to start?

The risks of agentic chaos
Listen to article
00:00 00:00

The use of AI in production environments has steadily grown and increased in complexity over the past two years. Even six months ago, “using AI” meant you were coding with GitHub Copilot or ChatGPT on the side. Then Cursor and Codeium brought AI to the IDE, while Perplexity, Claude, and other LLMs offered easy in-browser answers and code completions when you got stuck. 

More recently, we’ve seen AI integrated directly into widely-used B2B software, like Jira with Rovo, and others. Now, it’s just expected that AI lives everywhere, from the browser to your IDE and terminal.

But as companies test AI agents in production environments, a new challenge has emerged. Replit recently admitted that an AI agent used in production accidentally wiped their entire codebase, and then tried to cover up its tracks — kind of like an embarrassed junior coder trying to hang onto their job.

What once was just ChatGPT is now a chaotic swarm of AI agents, LLMs, MCPs, AI tools, and workflows surrounding the developer from within (and beyond) their IDE. With the rise of MCP servers, you can connect your AI assistant to a variety of tools that live in Figma, PagerDuty, GitHub, New Relic, and others. You’re still technically using “one” AI tool, but it’s now connected to 10 others.

At scale, this presents a massive challenge: imagine a 100-person developer team, each using five different AI tools or agents, with little guidance as to how to use them, train them, or control their output. That’s 500 possible connections at minimum that you need to govern. This is agentic chaos. 

In this post, we’ll talk about how tool sprawl includes AI agents and the top problems facing software developers in the age of agentic chaos — and how you can solve them. 

Why engineering leaders are concerned about agentic AI

A recent LeadDev survey of Engineering Leadership reports that 72% of leaders are concerned about the quality of AI-generated outputs, while another 49% are concerned about AI’s impact on code maintainability:

Image description: A graph displaying data from LeadDev’s 2025 Engineering Leadership Report on leaders’ biggest concerns regarding generative AI.

That concern appears to be growing year over year, presenting a new challenge:

As agentic AI improves, leaders have reason to question its ability to perform at the same level as their human counterparts, and at a faster pace. Using AI at scale means more tools, more agents, more LLMs, and more competition for your and your teams’ attention. 

It’s similar to what happened with the DevOps revolution. Every few months a new tool or dashboard emerged, and engineering teams had to pivot and adapt to keep pace with technological advancement. 

The difference is that AI doesn’t sleep. It works around the clock. 

While you can provide instructions and high-quality prompts it can use to reason through any problems it encounters, it still has a “mind” of its own. You can assign it tasks, but typically each agent requires a bit of clarification and hand-holding before it can properly execute a task. 

Even with proper guidance, AI is still new, and that means more time spent on review, more code to fix, and more that can go wrong. As Replit shows us, AI can delete your production database, provide bad quality code that takes more time to fix, or use an outdated library that later causes a security issue. Any of these issues, when merged to production without proper checks, can be catastrophic.

As a result, developers’ responsibility must expand from coding to managing human-to-machine and machine-to-machine communication. Developers no longer just build and run their software — now, they must orchestrate the AI agents who do. 

Agentic chaos is more than AI tool sprawl

We already know that developers suffer from dev tool sprawl according to our 2025 State of Internal Developer Portals report. With an average of 7.4 tools already in use without accounting for separate AI tools, the prospect of adding 10-15 new agents from different sources quickly spells trouble. 

Image description: A graphical representation of how increasing the number of tools you use, including AI tools and agents, can introduce tremendous risk to your organization.

We also know it’s pretty easy to spin up new AI tools: as long as you have an API key or access to LLM tokens, you can spin up as many AI agents as you want, from as many sources as you want. Governance is minimal. Access is fragmented. There’s no real control.

What makes this even worse, however, is that AI still lacks human-level reasoning abilities. “Controlling” AI means more than being choosy about which tools you use, it means preventing AI from doing harm to your database, codebase, infrastructure, and production environments. It means creating — and codifying — human- and machine-readable instructions, so that AI can’t modify schemas, make PRs, deploy code, or modify cloud infrastructure without approvals. 

With little oversight, uncontrolled AI imposes a major security risk to organizations, in addition to negatively impacting code quality and uptime.

Why MCP servers aren’t enough

Some leaders may look to an MCP server as a solution to make both devs and AI agents more powerful. But not all MCP servers are created equal: some require lengthy configuration processes and local hosting. Authentication is mainly done using API tokens or credentials that can expose potential security risks if the AI doesn’t use them properly. 

The many differences among MCP server configurations add up to one thing: they may not always be stable and can ultimately confuse the AI agents. Real usage shows agents need focus and guardrails to produce the best output. 

Port’s MCP server is “one to rule them all” — a preset, configurable MCP server that comes integrated into both your IDP and tech stack, ensuring that everyone, human or AI, who interacts with it will access the same dataset. We’re able to do this by connecting our MCP directly to your IDP, which combines their powers to solve tool sprawl issues by combining all of your tools, not just AI, into a single UI.

This improves many aspects of developer experience by reducing:

  • Chance of introducing bugs or vulnerabilities: With golden paths baked into self-service actions, developers are less likely to make mistakes when using new languages, systems, or software.

  • Overall lead time for changes: Devs spend less time navigating among different tools via portal integrations, accomplishing more in shorter timeframes.

  • Cognitive load: Developers no longer have to navigate unfamiliar systems while accomplishing infrequent tasks or migrations.

  • Cost of software development: Devs can save up to 6-15 hours per week, which for a team of 50 developers can mean savings of over $1 million in one year.
With AI now even more prevalent than when this survey was conducted, centralized teams like a DevOps or platform team, need to expand their scope to take over AI approvals and governance. 

All of these benefits apply to AI tools and agents as well, within the context of an internal developer portal, because all of this necessary control infrastructure will already exist. If your organization has invested in an internal developer portal and applying platform engineering best practices, consider this potential setup for addressing agentic chaos, as compared to how IDPs reduce chaos for human devs:

| Port features | Value to human devs | Value to AI agents | |---|---|---| | Blueprints | Visualizes the entire relational model among the components of your SDLC, demonstrating how dependencies flow | Provides AI agents a map to your ecosystem to help with navigating and taking action | | Software catalog | Provides crucial engineering context for the domain, including instructions, prompts, historical code changes, and third-party engineering data | Provides the same data as for human devs, but in a machine-readable format via a single API and built-in MCP server that make context engineering easy | | Self-service actions | Easy-to-use, standardized, and independent functioning throughout the SDLC based on meeting organizational software standards | Clear deployment paths for every agent, designed for specific task completion according to organizational software standards |

Role-based access controls, which you can clearly define alongside things like ownership details in your IDP, ensure that AI agents can only access the information they need. You can configure AI’s access to things like self-service and the software catalog the same way you did for human developers’ access, and control further for unusual situations. 

For example, if you define that your S3 bucket must follow certain visibility criteria, use a specific IaC form, and use a certain naming convention, then no agent will be able to break these rules. This is how you prevent things like deleting your entire codebase by accident.

If you use an IDP to manage human devs and help them be independent, it’s pretty easy to expose further instructions to AI agents for the same things! AI tools can then become part of your dev toolbox, like a ticketing system or a logging library. 

We already see developers using AI agents across the SDLC: handling incidents, resolving security issues, writing features, and testing, deploying, and writing docs. Greater use of AI agents will, over time, shift the developer’s job from coding to managing. Developers will start to resemble engineering managers, except without the 1:1s and performance reviews because their reports will be AI.

The top problems ahead

1. We need to control AI (and avoid a governance crisis)

Agentic chaos represents a material threat to your organization’s governance and sustainability. Platform engineers need to master these new tools quickly while creating guardrails that prevent cascading failures across services. You must build governance frameworks that work at AI speed. 

This can look like creating guardrails to prevent failures, as well as enabling your teams to move fast, so they can keep up with AI and restrict its behavior to keep within bounds, using scoped tools and governed controls.

The challenge is doing this while developers are already experimenting in production — and Port can help with that.

2. We need to keep up with AI’s pace (and keep humans in the loop)

Humans remain essential for code validation and approval. Agents don’t sleep, don’t take coffee breaks, and reason through issue triage faster than humans can, especially when provided the right context.

If AI agents can work 24/7, developers must evolve. No longer blocked by slow builds, developers can skill up to become the architects, reviewers, and orchestrators for their AI agents and tools. 

Platform engineers and DevOps teams must create checks and balances within their SDLCs to prevent AI from making commits and changes without humans, but which doesn’t prevent them from working around the clock. 

The bottleneck shifts from a platform limitation to a human limitation. Keeping pace with AI is both a requirement for safety and the biggest constraint on AI-driven productivity gains.

3. We need to teach AI (by codifying knowledge and what success looks like)

Your agents’ success will depend on the use case they’re deployed to handle, your preferences, and team standards. But AI needs a clear evaluation of what good looks like to be successful. 

You and your teams need to invest in a method of defining a place where your software standards, rules, working agreements, and domain language are codified in such a way that AI can consume and internalize it, like an internal developer portal.

Most organizational knowledge currently lives in stale documentation, wikis, Slack threads, and people's heads — places AI can't reach or won’t find much value in. This needs to change, not only to give AI access but to improve your developers’ troubleshooting abilities when things go wrong. The hidden cost will be transforming institutional knowledge into systems that AI can understand.

This is where an internal developer portal can help. When everything needs to be explicit, both human- and machine-readable, and constantly updated, only a real-time data relations model and accurate software catalog can enable AI agents (and human devs) in the context and at the speed they need. 

Image description: A Venn diagram illustrating the needs overlap that exists between human devs and AI agents. An internal developer portal can deliver all of this context, in both human- and machine-readable formats. 

Portals are designed to be one-stop-shops for all the context of your SDLC. AI agents, when connected to your IDP via something like an MCP server, can contextualize the important, domain-specific needs of your organization.

Building toward an agentic future

What we’ve described here is a paradigm shift: developers and software engineering teams will need to continuously adapt to a future where agent-to-agent communication is more common and complex. Eventually, each developer may have 10 or 15 parallel threads with agents running different tasks.

Soon, we’ll see widespread adoption of agentic AI that no longer just suggests code, but writes and executes on complete workflows. You, the human dev, are now its manager handing off and prioritizing your agentic workforce. They respond, you review.

To grow into this new future, you’ll need to stay organized, provide clear guidance to your AI agents and the human devs using them, and monitor their actions in real time.

Tags:

General
{{survey-buttons}}

Get your survey template today

By clicking this button, you agree to our Terms of Use and Privacy Policy
{{survey}}

Download your survey template today

By clicking this button, you agree to our Terms of Use and Privacy Policy
{{roadmap}}

Free Roadmap planner for Platform Engineering teams

  • Set Clear Goals for Your Portal

  • Define Features and Milestones

  • Stay Aligned and Keep Moving Forward

{{rfp}}

Free RFP template for Internal Developer Portal

Creating an RFP for an internal developer portal doesn’t have to be complex. Our template gives you a streamlined path to start strong and ensure you’re covering all the key details.

{{ai_jq}}

Leverage AI to generate optimized JQ commands

test them in real-time, and refine your approach instantly. This powerful tool lets you experiment, troubleshoot, and fine-tune your queries—taking your development workflow to the next level.

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_survey}}

Check out the 2025 State of Internal Developer Portals report

See the full report

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical walkthrough of Port

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta-demo}}
{{reading-box-backstage-vs-port}}
{{cta-backstage-docs-button}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start