ai/agents ai/enterprise platformengineering gitops casestudies wso2 conference
Core idea
Platforms must become usable by agents, not only by human developers. Artem Lajko presents agentic platforms as an evolution of GitOps-based platform engineering. Agents need reliable, consistent interfaces to platform capabilities, machine-readable state, and controlled identities and permissions. This builds on platform foundations that make deployments declarative, repeatable, and scalable.
Video
1. From manual operations to GitOps
Lajko describes the move from configuring infrastructure by logging into individual machines, through infrastructure-as-code tools and pipeline-driven operations, to GitOps. In GitOps, Git stores the desired state and acts as a contract between the user and a continuously reconciling agent. The agent detects and corrects drift, including removing resources that are no longer declared.
He summarizes the core principles as:
- Declarative state: Specify the desired outcome rather than each operational step.
- Versioned, immutable change: Keep changes in version control as reviewable artifacts.
- Pull-based operation: The agent retrieves desired state rather than relying on direct inbound control.
- Continuous reconciliation: The agent checks actual state against desired state and corrects drift.
These properties support repeatable management across fleets, not only individual clusters. Lajko says one of his projects aims to manage 15,000 clusters. This is a project scale he describes, not a benchmark or outcome established in the talk.
2. Design the platform for scale
A platform can hide repeated low-level configuration behind workload templates, abstractions, or custom resource definitions. Developers provide the values they need, while the platform supplies the underlying manifests and operational conventions.
Lajko cautions that scaling requires more than selecting a GitOps engine. Teams must consider how to organize platform planes, distribute controllers, and shard work. He outlines several deployment patterns:
| Pattern | Trade-off described in the talk |
|---|---|
| Hub and spoke | Central management is convenient, but a compromised hub may expose broad access. |
| Dedicated controllers per cluster | Provides isolation, but uses more resources. |
| Hybrid approaches | Combine central management with workload deployment, but require more platform design. |
| Agent-based pull | Agents pull from a hub, avoiding inbound access to managed environments. Lajko says this can be easier to approve in regulated and on-premises settings. |
He also describes a “Gitless” direction for distributing deployment artifacts: use OCI registries rather than repeatedly polling Git for rendered manifests. Git remains useful for human collaboration, while OCI artifacts can serve as immutable distribution units for large fleets. This is the speaker’s architectural argument, not evidence that OCI is the only suitable option in every environment.
3. Internal developer platforms need developer adoption
Lajko frames platform engineering as a response to the limits of loosely coordinated DevOps responsibilities. A platform team should provide self-service, reduce developer cognitive load, improve developer experience, and choose useful abstraction boundaries.
He warns that building an internal developer platform is costly and difficult. Citing 2026 HackerNoon figures, he says an 18-month build may cost about $4 million and require five to ten years of engineering experience per engineer. He also cites a 64% platform-bypass figure. These are figures he attributes to the source; the talk does not establish their methodology or scope.
His practical concern is that platforms often reflect a systems-engineering mindset instead of developer needs. A portal such as Backstage is not, by itself, a complete production-ready platform. It is a framework that requires implementation and integration. Teams should understand what users need and avoid assuming that deploying a portal will create adoption.
4. Make agents first-class platform users
The next step in Lajko’s account is an agentic developer platform. Agents should use the platform’s real capabilities and interfaces, rather than operate through ad hoc access or a separate set of APIs.
The platform foundations he identifies include:
- Clear identity: Attribute actions to a specific agent for follow-up and audit.
- Bounded capabilities: Grant only the operations an agent needs.
- Sandboxing and policy controls: Limit the impact of agent actions.
- Observability: Inspect activity and diagnose what happened.
- Consistent interfaces: Keep the portal, API, CLI, Git-based workflows, and agent interfaces aligned where possible.
- Human review: Preserve platform-team review for changes to shared capabilities.
Lajko notes that agents can also operate a platform, as in site-reliability or FinOps tasks, rather than only consume its services. This makes identity, permissions, observability, and audit important for both agent users and agent operators.
5. An example workflow for extending platform capabilities
Lajko proposes a workflow where a developer asks an agent for a missing component type. The agent examines machine-readable platform definitions and drafts a new custom resource or related capability as a pull request. Platform engineers review and adjust it, then merge it. GitOps can deploy the approved capability so developers can use it.
The intended benefit is faster collaboration between developers and platform engineers, with agents helping translate a need into a reviewable implementation. This is a proposed workflow and expected benefit, not a measured result reported in the talk.
Key takeaways
- GitOps makes desired state explicit and continuously reconciled. This supports consistent operations across many workloads and clusters.
- Scale is an architecture problem. Controller placement, planes, sharding, and artifact distribution matter alongside the GitOps tool.
- A portal is not the whole platform. Adoption depends on useful abstractions and a platform shaped around its users.
- Treat agents as platform identities. Give them clear interfaces, bounded capabilities, observability, and audit trails.
- Use agents to improve collaboration, not remove review. The example keeps platform engineers responsible for approving shared capabilities.
Related vault notes: The Evolution of Platform Engineering gives a broader platform timeline; Building an Agent-Ready IDP with Open Source Tools and OpenChoreo - Building AI-Native, K8s-First Platforms explore agent-ready platform design.
LLMs and AI Agents, 6. Reflexes and Guardrails, Closing the AI Execution Gap with Forward Deployed Engineering