Agentic engineering platform: The evolution of IDPs

Internal developer portals are changing. Read all about Port’s next evolution, the agentic engineering platform.

October 20, 2025

Ready to start?

Agentic engineering platform: The evolution of IDPs
Listen to article
00:00 00:00

We are at the brink of a software engineering revolution. AI is here to stay, and not just as a coding assistant. 

AI is here to make software. AI will take what was a manual engineering process — writing code, enriching tickets, writing PRDs, managing incidents, eliminating vulnerabilities, handling tech debt — and turn it into an autonomous, agentic engineering process. 

Agents now write their own code, unit tests, and run PR checks. With clear instructions and a well-written prompt, you can make an AI assistant do just about anything. It melts away the administrative work of manual engineering.

But soon, AI will become more than an assistant. Agentic AI promises full autonomy: AI agents can serve as incident managers, product managers, team leads, developers, and policy judges, working across the software development lifecycle (SDLC) in harmony to deliver world-class software successfully, safely, and faster than ever before.

The vibe is shifting — manual engineering is becoming agentic engineering. But how did we get here? And what does it take to get agentic engineering right?

DevOps promised agility, but created engineering chaos

The software development industry changed significantly after the introduction of DevOps practices and cloud-native computing technologies. Developers became responsible for the entire SDLC, which meant they now had to be experts within the complex cloud-native environment. This was impossible for them to achieve without guardrails and guidance.

Unifying the SDLC under developers fractured the systems on which software is built. The industry had to create a distributed, scalable and automated SDLC:

  • Monoliths broke apart into microservices
  • Kubernetes took over for Docker swarm / Heroku or on-prem hosting
  • GitOps
  • Dozens of CI/CD processes and automated jobs were required to automate processes
  • Many new technologies were adopted to monitor, secure, and track the distributed environment 

The fracture of these systems and responsibilities created what we call engineering chaos: 

Engineering chaos resulted in tool sprawl, stale documentation, and static infrastructure docs in a real-time world.

Engineering chaos made systems and environments difficult to work with, vulnerable, nonsecure, and confusing. This resulted in more tickets, stale documentation, and static infrastructure documents saved in Excel, and created silos between different teams that contributed to a lower quality developer experience. 

Service ownership was not clear, data was scattered across many different tools, standards were hard to maintain, and code got kicked back for additional testing or improvements, proving that much of the important context needed to produce software relied on institutional knowledge. 

Production-readiness requirements changed, and as a result, they weren’t clear. Developers created an increasing amount of tickets for DevOps teams, requesting resources or permissions to access them. Onboarding times for new engineers also increased as a result of this complexity.

Port originally emerged to eliminate engineering chaos. We started by getting things under control, abstracting away the complexity of modern cloud-native environments with a single internal developer portal (IDP) for all technical teams. Our goal was to unify all of these tools, environments, systems, and stakeholders in development into a single team.

Port's IDP was built to tame engineering chaos.

This chaos needed taming, which meant engineering teams needed distributed, scalable, and adaptive development lifecycles to manage. Developers needed a single place to manage more than code. Team leads needed to create and enforce new coding standards and frameworks to make sure features made it to market within expected time frames. Managers needed to mitigate the costs of developing in expensive cloud environments and better speak to the throughput, satisfaction, and velocity of engineering teams.

We founded Port to eliminate this organization-wide chaos. Our IDP has always been intentionally flexible, to adapt to our customers’ dynamic needs, engineering culture, and tech stacks as technology evolved.

But we quickly realized that engineering chaos was a bigger problem than we first thought.

From engineering chaos to agentic chaos

At the start of the year, we started hearing from customers about their challenges with integrating AI directly into their SDLCs. They told us, “We want to take AI agents beyond coding assistants. We want AI to resolve tickets and take them all the way to production, we want it to self-heal incidents, we want it to continuously clear vulnerabilities.”

The promise they saw in AI was clear: it could exponentially multiply the speed, safety, and efficiency of software development. 

But AI wasn’t performing this way. The generated code acceptance rate was lower than expected and sometimes required significant refactoring to meet standards. AI’s decisions were not predictable, and they would often take destructive decisions like deleting databases. An uncontrolled AI agent can do real damage: Jason Lemkin’s Replit AI agent accidentally deleted SaaStr’s entire production database during a vibe-coding session. 

Engineering chaos complicates AI adoption

Existing engineering chaos only made things more difficult. Confusing documentation and a lack of standardization across teams have long plagued companies looking for efficiency gains and a faster time-to-market. Teams have always needed to address this chaos and gain control over their systems.

But with AI in the mix, this problem gets exponentially worse. 

The threat of agentic chaos is real

As we’ve written previously, when you unleash AI into your SDLC without guardrails or workflows that keep it in check, your engineering chaos turns into agentic chaos: 

Agentic chaos is engineering chaos made exponentially worse as a result of introducing AI.

When AI is introduced to your engineering environments without context, such as knowledge about your application architecture, dependencies, or ownership teams, it can’t act safely. 

Our vision: Moving the industry from manual engineering to agentic engineering

Not all companies are experiencing agentic chaos in production yet, but it won’t be long before it arrives. Gartner predicts that companies’ average AI agent-to-human developer ratio will eclipse 100:1 in the next 18 months. If this bears out as it did for Replit, your existing engineering chaos is only going to explode.

But what if we make our internal developer portal more accessible to AI? With a wealth of engineering context running through the IDP in real time, AI could act more nimbly. Golden paths, which helps developers create better, reusable workflows and pipelines to production, might also help with directing AI. 

AI isn’t able to reason through things the way a human can. Moreover, it needs to be onboarded to your systems in structured, measured ways.

Orchestrating AI means more than making sure two endpoints connect — you have to protect the systems you’ve built from destructive actions, rogue AI, and onboard AI agents to your environments with rigor, structure, and context. 

When you can successfully orchestrate AI across your SDLC, from writing code all the way to maintenance and incident management, you unlock agentic engineering. 

Agentic engineering is the future

A recent MIT report supported our thinking: 95% of the AI pilots conducted at companies this year failed to return results due to brittle workflows, a lack of context, disorganized documentation, operational immaturity, and a lack of standardization. 

When we dug in, we realized two things: 

  1. AI needs to be integrated as deeply into your systems as humans are — and perhaps even more deeply. It needs context, data, guardrails, and actions to be codified and accessible to be successful.
  2. Our internal developer portal was uniquely positioned to evolve to provide that context, data, guardrails, and actions to AI agents, while making their actions, outputs, and context windows visible to and auditable for humans. 

What we’ve found in talking to customers, conducting our own research, and experimenting endlessly with AI ourselves, is that a major root cause for these challenges actually wasn’t so new. It was the problems of yesterday keeping us from the promise of tomorrow: chaotic environments only breed more chaos.

In other words, existing engineering chaos complicates companies’ AI adoption — and will quickly contribute to agentic chaos. And as the report also indicated, existing solutions aren’t quite robust enough to handle AI and humans equitably.

So, when our customers started asking, “How do we start to trust AI?” We had an answer ready: the agentic engineering platform. 

Introducing Port’s agentic engineering platform

To unlock agentic engineering, you need deep, rich, real-time engineering context. You need guardrails. You need auditability. And you need a human-to-agent collaboration experience to help them work together.

Port is evolving to meet this need. The internal developer portal will evolve into an agentic engineering platform, which will open all of the IDP’s benefits to AI. It harmonizes people, agents, and infrastructure, accelerating software delivery and elevating standards without sacrificing control. 

To begin this evolution, Port is adding three new pillars to the platform:

  1. A context lake where agents consume data and take action
  2. Guardrails to prevent destructive agents behavior
  3. A human-to-agent collaboration interface

These pillars contain all of the context, tools, and policies that an AI agent needs to effectively develop software safely and successfully. 

More than embedding AI into your SDLC, AI becomes a first-class user of the platform, becoming as effective at developing software as your engineers, without fear of losing control.

This is how you finally trust AI. 

With our agentic engineering platform, we hope to do more than address gaps in agentic AI adoption. We want to deliver on the fully autonomous software development lifecycle, where platform engineers can design any autonomous workflow:

  • Automated ticket resolution
  • Self-healing incidents
  • Autonomous application security posture management 

We invite you to join us in building this future. Follow us on LinkedIn and stay tuned for more updates as we bring the agentic engineering platform to life. 

{{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