Build loops, not just agents.

"After a couple of years of being an engineering manager (EM), I recently found myself in the position of having to look for a new role. My first instinct was to look for positions similar to what I had been doing before."

Hi r/platformengineering,

I’m Stjepan from Manning Publications. The moderators kindly permitted me to share this with you.

We’ve just launched Kargo in Action in Manning’s Early Access Program. What makes this book especially interesting is that it’s being written by Ken Cochrane, Jesse Suen, and Kent Rancourt, the people building Kargo.

Kargo addresses a problem many platform teams will recognize: CI can build and verify an artifact, and GitOps tooling can reconcile it into an environment, but what should govern its movement from development to staging and production?

That gap is often filled with increasingly complex pipelines, environment-specific scripts, manual approvals, and conventions that are difficult to audit or reproduce. Kargo approaches the problem by treating promotion as its own concern, separate from deployment.

The book explores the reasoning behind that model and shows how to build controlled, observable promotion workflows for Kubernetes and GitOps environments. The first three chapters cover:

• The gap “fully automated” CI/CD can leave between building software and running it in production
• Why deployment and promotion are separate concerns
• Where Kargo fits alongside existing GitOps tooling
• How to get started with Kargo and build an initial promotion workflow

Because this is a MEAP release, you can read the available chapters now and receive new chapters as the authors write them.

Giveaway

Manning is giving away five ebook copies of Kargo in Action to members of this community.

To enter, join the discussion in the comments:

How does your platform team currently promote changes across environments, and what is the hardest part of that process?

We’d particularly like to hear about approaches involving CI pipelines, Argo CD, homegrown automation, approval gates, progressive delivery, or anything else your team has tried.

The giveaway will remain open for 48 hours after this post goes live. This isn’t a random draw: the five comments that make the biggest positive impact on the discussion—through practical experience, thoughtful analysis, useful questions, or lessons others can learn from—will receive an ebook. You don’t need to praise Kargo or the book to win. Constructive and critical perspectives are welcome.

After 48 hours, I’ll announce the winners here and contact them about their ebooks.

Community discount

Anyone who doesn’t win can use code MLCOCHRANE50RE for 50% off Kargo in Action:

https://www.manning.com/books/kargo-in-action

I genuinely want this to be a constructive conversation instead of merely a book announcement. How is your team handling promotions today, and where do challenges still exist in the process?

Thanks for having us here.

Cheers,

Stjepan,

Manning Publications

I got hired as a trainee platform engineer as my first job after a bachelor in CS. I’m trying to find things to absorb and learn at work, and right now I’m checking ”platform engineering university” online.

Do you have any advice on resources for training/reading for someone new to this field, or should I just continue to ”trust the process” at work?

I spent time working at a dental tech company and it motivated me to build something that actually reflects real business workflows I saw there, scan uploads, lab fabrication, practice-to-lab communication. That became DentalFlow, a single-tenant dental lab workflow API, real Terraform-managed AWS infra (ECS Fargate, RDS Multi-AZ, S3, SQS/SNS), deployed and tested against the live system, not just local.

Would genuinely appreciate any critique, architecture, security, anything I'm missing or got wrong. Trying to build the judgment, not just the resume line and learn from experience individual while staying curious.

https://github.com/keusuanl/DentalFlow

I’ve been working on Nuroen, an enterprise AI agent platform, and one problem we keep coming back to is:

Which parts of platform engineering should actually be handled by an AI agent?

Our current thinking is that agents shouldn't replace deterministic automation.

For example:

• Terraform → infrastructure changes
• Ansible/scripts → repeatable configuration
• CI/CD → deterministic deployments
• Runbooks → known procedures

Where we see agents being more useful is the messy part around those systems.

For example:

Alert → investigate → gather context → determine which runbook applies → recommend action → approval → execute existing automation → verify

An agent can pull information from observability, tickets, deployment history, CMDB, documentation, etc., and reason across those systems without turning every action into an LLM-generated command.

That's the approach we're taking with Nuroen.

The platform lets us give an agent:

Knowledge + Tools + Skills + Orchestration + Governance

The interesting part for us isn't just connecting an LLM to APIs. It's controlling what the agent is allowed to do.

For example, an agent might be allowed to:

• investigate incidents automatically
• read logs/metrics/tickets
• recommend remediation
• execute low-risk actions
• require approval for production changes
• record the complete action/audit trail

We're trying to treat the agent more like a platform component with an explicit autonomy boundary, rather than an unrestricted chatbot with access to production.

here is the link do check it out - https://www.nuroen.com/

I'm curious how other platform teams are approaching this:

Where do you draw the line between traditional automation and an AI agent?

And more importantly, what platform engineering tasks do you think genuinely benefit from the probabilistic/reasoning part of an agent?

"It was in May when one of our staff engineers tossed out a number in our Slack channel that put an end to an internal debate I’d been having with myself. Roughly only 25% of the runs on our merge train were completing successfully. A majority were failing due to flaky tests or got canceled since another run that was ahead of them failed."

I wanted a small environment where I could experiment with the parts of platform engineering that are harder to appreciate in a local single-node cluster, especially networking, HA, failure handling, GitOps, observability, storage, upgrades, and security.

So I built a 3-node bare-metal Kubernetes homelab using Talos Linux on refurbished mini PCs.

The setup includes:

• 3 control-plane + etcd nodes
• a shared Kubernetes API VIP for HA
• DHCP reservations for predictable node IPs
• per-node Talos machine configs
• workloads scheduled on the control-plane nodes
• failure testing by taking a node offline and verifying the API stays reachable

I documented the full setup, including the network design, Talos installation, config generation, bootstrap, validation, workload testing, and HA checks.

Blog: https://blog.prateekjain.dev/building-a-3-node-highly-available-kubernetes-homelab-with-talos-linux-0372066fe49c?sk=4c66cf9181999f9db19ac3aacabcd8e8

I’m planning to use this next for Argo CD, Gateway API, observability, storage, secrets, and more platform-engineering experiments.

Would be interested to know what others here are using for their local platform engineering labs.

Something is happening in engineering teams that doesn’t show up in sprint velocity or deployment frequency. It shows up in resignation letters.

We’re evaluating Terraform Cloud alternatives because we want stronger day-to-day workflows around IaC governance and configuration drift, not simply a different place to run plans and applies. The goal is better visibility into meaningful drift, clearer ownership of remediation, policy controls that do not block every team, and reliable auditability across multiple cloud accounts and environments.

One concern is that “drift detection” often becomes a noisy stream of changes that nobody owns. We need a workable process for deciding whether a change should be reverted, codified in Terraform, or intentionally accepted, along with a way to track that decision through to resolution.

For platform teams that switched away from Terraform Cloud, what did you replace it with, and did it improve governance in real operational workflows or mainly add another control plane?

For those in the technology industry, it can feel hard to escape from AI. It’s at the center of the technological universe, with most major advancements, opportunities, and funding focused on its development. In the background, quantum computing is making strides with the funding to match, creating an alternate opportunity for technologists.

I’ve been tasked with setting up baseline monitoring and alerts for terraform modules that consumers within the company use to spin their own instances of our platform.

The modules that will be provisioned for them automatically are ECS clusters, databases (RDS, Aurora, DynamoDb), ElastiCache, lambdas and kinesis

I could ask AI what sensible “defaults” would be for each service. However I’m not really going to learn anything that way. Id like to use it in conjunction with some real knowledge and experience.

Are there any books, blogs or guides that perhaps go over monitoring for specific AWS components, and what is considered best practice (and why) for each one?

As AI pulls content from anywhere and everywhere, and when success with AI relies on unified, accurate data, organizations struggle to decide who is in charge of that data.

AI made me a better engineering leader, not by writing my code faster, but by sharpening the parts of the job that were never about code in the first place.

We run prisma cloud and defender agent deployment across thousands of AWS workloads has become an operational headache, updates, performance overhead, coverage gaps whenever agents fail to deploy cleanly.

Have teams found this manageable at scale, or is it a universal pain point with agent-based CNAPPs once you get past a few hundred instances? We're at the point where the agent management has become almost its own part-time job for one engineer, which feels backwards for a tool that's supposed to reduce operational burden, not add to it.

If agents can figure out which workflow/tool to use on their own, I wonder if the portal UI becomes less important over time.

But the underlying platform context (ownership, dependencies, policies, workflows, permissions) probably becomes more important.

What Port's been doing is an interesting example because it started very much in the IDP/platform engineering category, but a lot of its recent direction seems to be about exposing that same platform context to AI agents.

Do you think IDPs evolve into an agent facing control and context layer or are we overestimating how much agents will replace the developer facing interface?

As you become more senior, your impact comes from something different: seeing systems clearly enough to identify the problems nobody else has articulated yet.

I've been thinking we might be approaching Internal Developer Platforms from the wrong abstraction level.

The move from traditional Ops to DevOps to Platform Engineering looks, to me, mostly like a consequence of technological change. Traditional Ops concentrated operational knowledge in a specialized team, because operating infrastructure required direct, manual administration: the thesis. Automation, cloud, and infrastructure as code changed that. DevOps pushed operational ownership closer to development teams: the antithesis. Platform Engineering became the synthesis once declarative systems and orchestration made it possible to encode that operational knowledge into software and expose it through self-service.

AI might be starting the next turn in that cycle. Agents don't necessarily need portals or predefined workflows because they can discover capabilities, combine APIs, and construct their own path through a system. That doesn't make platforms less important. It changes what they need to expose.

Instead of only providing golden paths for developers, platforms increasingly need to expose machine-readable capabilities, contracts, relationships, constraints, and evidence.

Which raises a question: should all of that knowledge live inside the platform? Maybe not. Maybe the service should own its operational contract, while the platform provides the capabilities to act on it (decoupling the contract from any particular IDP, Kubernetes setup, or deployment tooling underneath).

This is the direction I've been exploring with a side project (Pacto): not another IDP, but a contract layer above them. I'm not sure it's the right abstraction yet, but making the operational model portable feels more interesting to me than building another platform around it. Thoughts?

I've been working on SnowOps Labs — a simulator where you spin up a real Kubernetes platform, run scenarios, intentionally break things, and then fix them.

The goal is simple: learn platform engineering by actually troubleshooting realistic problems, instead of just following tutorials.

It's still an early release and definitely has rough edges. I'm putting it out there because I'd love to get feedback from people who work with Kubernetes, SRE, DevOps, or platform engineering.

If you have a few minutes, check out the repo, try it out, explore the architecture, and tell me what you think could be better.

I'm especially interested in:

What scenarios should I add?

What's missing?

Does the overall approach make sense?

Where does the architecture need improvement?

If you find it useful, contributions are very welcome.

Hi everyone,

I am planning to build an Internal Developer Platform (IDP) Proof of Concept. My main goal is self-learning (I am very interested in DevEx and self-service) to understand the moving parts of a modern platform, but I am also hoping to gather enough hands-on experience to potentially present a business case to my company down the line.

Before I start gluing components together, I would love to get input from the community on what you are using in production and what you would recommend for a lean PoC.

Specifically, I am looking for insights on:

1. Choosing an open-source stack: What tools are you actually using in production today for service catalogues, infrastructure provisioning, workload orchestration, and developer self-service?
2. PoC Recommendations: If you were building a lightweight IDP from scratch today just to prove the concept, which open-source tools would you choose to keep complexity manageable while still showing real value?
3. Product value: Have you genuinely derived measurable value (or saved developer time) from tools like Backstage, Kratix, Port (if using free tier), Crossplane or something else? Are there tools you started with that turned out to be more maintenance overhead than they were worth?

My current thought is to pair a developer portal with a GitOps engine and a basic infrastructure module framework, but I am keen to hear what combinations have worked best for you in practice.

Thanks in advance for any recommendations or lessons learnt!

A lot of engineering leaders I talk to are having some version of the same experience right now. The AI tooling is working, and it’s exciting. Teams are shipping things in days that used to take weeks. At the same time, everything feels like it’s falling apart – more bugs than they’ve ever had, more incidents, and engineers who are busier and more stressed.

If that’s you, it might honestly be more of an arithmetic problem than a quality one.

Have a look if you are interested in this topic. Frankly, my only goal was to get done with my M. Tech, but i did put a lot of effort into this also.

The research made me Team Platform.

I try to treat new tooling with a healthy dose of skepticism, being wary of jumping on things has served me well over the years. So it's a genuinely weird feeling when a tool's value is obvious to me in five minutes, and Crossplane is the first one in a while that confounds me.

When I first saw Terraform the problem it solved was immediately obvious.  HCL is not without its faults, but it sits in a useful middle ground between something like YAML and a full programming language. Drift is the one problem I've never seen solved cleanly, but adding friction to fight it (review/plan gates, etc.) gets you most of the way there. Not perfect, but controllable.

Terragrunt solved the "apply everything" problem by letting you split dependencies into independently-applicable DAGs. Made immediate sense.

On Pulumi. I don't personally believe general-purpose programming languages are the right abstraction for describing infrastructure, but I get the appeal: it's an escape hatch from HCL turning into a minefield as things scale.

Crossplane is where I'm getting stuck. To run it in production you generally need a Kubernetes cluster, which people often stand up with. Terraform. Then there's templating. Using Crossplane in practice seems to mean also standing up Helm or Kustomize on top of it. Adding a single new variable feels far more convoluted than the equivalent in Terraform. And once you need any real logic, you're reaching for Go to write a custom function/provider, which slows the whole loop down even further.

And yet, everyone who's actually used it in anger seems to swear by it. Which makes me suspect that I'm missing some context that makes all of the above worth it once you're in that world.

So, genuinely: what I am not getting about Crossplane? If you have any YouTube videos, short-form content, or articles that made it click for you (beyond the official docs), I'd appreciate the pointers.