Coder Legion - Recent posts tagged platformengineering

System Design for DevOps Personnel Is More Than Knowing Kubernetes, AWS or Terraform.

Tue, 29 Sep 2026 05:30:47 +0000

Recently, I interviewed for a Staff Site Reliability Engineer (SRE) role, where I encountered some interesting system design challenges around building a scalable, highly available, cloud-native application.

The discussion reinforced an important lesson: Knowing individual technologies is one thing; understanding how to bring them together to solve real-world distributed systems problems is another.

Here are 5 key technical takeaways from the discussion that I'm revisiting and deepening my understanding of.

1. Cloud Networking: AWS vs. GCP

One interesting discussion was around designing DNS, VPCs and networking for a globally distributed application running on Amazon EKS.

A key distinction:

AWS VPCs are regional.
GCP VPCs are global resources.

For a multi-region AWS architecture, we need to consider separate regional VPCs, public and private subnets, cross-region connectivity using Transit Gateway or other appropriate networking patterns, and Route 53 for global DNS routing.

Key takeaway: Cloud architecture requires understanding the fundamental differences between cloud providers, not just their equivalent services.

2. Designing for Burst Traffic and High-Throughput Ingestion

How would you handle a user uploading 1,000 files in a single action without overwhelming Kubernetes application pods?

Autoscaling with Karpenter and applying rate limits can help, but neither alone solves the problem of sudden bursts in application-level traffic.

A more scalable approach:

Generate S3 presigned URLs through an API.
Allow clients to upload files directly to S3.
Trigger asynchronous processing through S3 events and SQS.
Use KEDA to scale Kubernetes worker pods based on queue depth.

This separates the ingestion data plane from the application control plane and helps absorb traffic spikes without overwhelming application workloads.

Key takeaway: Before scaling infrastructure, ask whether the workload needs to pass through your application in the first place.

3. Event-Driven Autoscaling with KEDA

Traditional Kubernetes HPA commonly relies on resource metrics such as CPU and memory.

However, for asynchronous workloads, these metrics may indicate a problem only after a backlog has already accumulated.

KEDA enables event-driven autoscaling using signals such as SQS queue length, allowing worker replicas to scale according to pending work, including scaling to zero where appropriate.

Key takeaway: Autoscaling should be driven by workload characteristics, not just infrastructure utilization.

4. Container Security and GitOps

Some areas that remain essential for production-grade Kubernetes platforms include:

Multi-stage Docker builds and minimal container images.
Running containers as non-root users.
Read-only root filesystems wherever practical.
Container image vulnerability scanning using tools such as Trivy or Grype.
Workload identity and least-privilege access using IAM Roles for Service Accounts (IRSA) on EKS.
CI/CD pipelines with automated testing, security scanning and image signing using Cosign.
GitOps-based deployments using Argo CD and Helm.

Key takeaway: Security and deployment reliability should be built into the software delivery lifecycle, rather than added after deployment.

5. Observability: From Reactive Monitoring to Proactive Reliability

Monitoring CPU and memory utilization is important, but infrastructure metrics alone don't tell us whether users are experiencing a degraded service.

A more comprehensive observability strategy includes:

The Four Golden Signals:

Latency, Traffic, Errors and Saturation.

Distributed tracing using OpenTelemetry.
Service-level indicators (SLIs) and service-level objectives (SLOs).
Synthetic monitoring to validate critical user journeys.
Actionable alerts based on user impact and error budgets.

Key takeaway: The goal of observability is not simply to detect infrastructure failures, but to understand and prevent user-facing reliability issues.

My biggest takeaway

A Staff-level SRE is expected to think beyond individual tools and commands.

It involves understanding trade-offs, identifying bottlenecks, designing for failure, managing cost, ensuring security and making architectural decisions that support long-term scalability.

There are always new technologies to learn, but the ability to reason about distributed systems and explain why a particular design decision makes sense is equally important.

I'm using this experience to strengthen my system design fundamentals and deepen my understanding of large-scale cloud-native architectures.

Continuous learning is an essential part of engineering growth. Every challenging discussion is an opportunity to get better.

Deploying Backstage on Kubernetes with the Helm Chart: The Infrastructure-First Guide

Fri, 17 Apr 2026 11:52:35 +0000

A practical field guide for engineers who start from the Backstage Helm chart — covering the real configuration gaps, the demo image limitation, and the exact values nesting that makes or breaks your deployment.

Who this is for: Engineers deploying Backstage on Kubernetes via the
official Helm chart who want a working portal, not just a running pod.
This guide starts where most tutorials end — after helm install succeeds
but before anything actually works.

A few weeks ago I published an article called
"Nine Ways Backstage Breaks Before Your Developer Portal Works".
A Backstage maintainer read it and gave me structured feedback. The core of
it was this: several of the failures I documented were caused by not
following the official getting-started documentation before using the Helm
chart, and by using the demo image as if it were a production-ready base.

They were right. This article is the follow-up they suggested — and the one
I should have written first.

It does not repeat the previous article. It starts earlier, goes deeper on
Helm-specific configuration, and correctly attributes failures to their
actual causes rather than blaming Backstage for things that are ArgoCD,
Traefik, or operator error.

Official resources you should read alongside this guide:

Project repo referenced throughout:
github.com/sodiq-code/neuroscale-platform

The one thing you must understand before installing the Helm chart

The Backstage Helm chart uses a demo image by default. The chart README
contains this explicit warning:

The Backstage chart is not an official Backstage project and is not
supported by the Backstage core team. The default image used in this chart
is for demo purposes only.

This single fact explains most of the configuration friction you will
encounter. The demo image does not behave like a real Backstage application
built with backstage new app. It has different startup characteristics,
different configuration defaults, and different failure modes.

What this means practically:

If you are building a real developer portal — not just running a demo — you
should follow the official getting started guide
to create your own Backstage application first, build a custom Docker image
from it, and then use the Helm chart to deploy that image. The chart's
image.repository and image.tag values are where you point to your
own image.

If you are experimenting, learning, or building an integration platform
where Backstage is one component (as in the NeuroScale project), the demo
image path is workable — but you need to understand its limitations and
configure it correctly.

This guide covers the Helm chart path specifically, with the official docs
as the reference point throughout.

The values hierarchy that breaks everything silently

This is the most important configuration concept in the entire Helm chart.
Get this wrong and every override you write will be silently ignored.

The Backstage Helm chart is a wrapper chart — Backstage itself is a
dependency inside it. The dependency is named backstage. This means
configuration for the Backstage application container must be nested under
backstage.backstage.*, not backstage.*.

Wrong — values are silently ignored:

# This looks correct but is placed at the wrong hierarchy level
backstage:
  appConfig:
    app:
      title: My Platform
  startupProbe:
    initialDelaySeconds: 120
  resources:
    requests:
      cpu: 100m

Correct — values reach the Backstage container:

backstage:
  backstage:           # <-- this second level is required
    appConfig:
      app:
        title: My Platform
    startupProbe:
      initialDelaySeconds: 120
    resources:
      requests:
        cpu: 100m

The Helm chart processes the outer backstage key as the dependency name.
Values placed directly under backstage.* are interpreted as chart-level
configuration, not as container configuration. Kubernetes then uses chart
defaults — including probe timings — rather than your overrides.

How to verify your values are actually applied:

Render the Helm chart before applying it and inspect the output Deployment
spec directly:

helm template neuroscale-backstage backstage/backstage \
  -f infrastructure/backstage/values.yaml \
  --namespace backstage \
  | grep -A 30 "startupProbe"

If you see initialDelaySeconds: 120 in the output, your probe override
reached the container. If you see initialDelaySeconds: 5 or a very small
number, your values are at the wrong nesting level.

This verification step should be part of your CI pipeline. In the NeuroScale
platform, scripts/ci/render_backstage.sh runs this check on every PR:

#!/bin/bash
# scripts/ci/render_backstage.sh
helm template neuroscale-backstage backstage/backstage \
  -f infrastructure/backstage/values.yaml \
  --namespace backstage \
  | grep "initialDelaySeconds" \
  | grep -q "120" || {
    echo "ERROR: startupProbe initialDelaySeconds not set correctly"
    exit 1
  }
echo "Helm values nesting verified"

Required configuration keys for the demo image

The demo image requires specific configuration keys to be present at
startup. Missing any of them causes the frontend to crash on load with a
JavaScript error that is only visible in browser developer tools — the page
itself shows a blank white screen with no visible error.

The minimum required appConfig block:

backstage:
  backstage:
    appConfig:
      app:
        title: Your Platform Name    # required — crash if absent
        baseUrl: http://localhost:7010
      backend:
        baseUrl: http://localhost:7010
        cors:
          origin: http://localhost:7010
        database:
          client: better-sqlite3
          connection: ':memory:'

Why baseUrl matters:

The app.baseUrl and backend.baseUrl values must match the URL you are
actually using to access Backstage. If you port-forward on port 7010 but
the config says port 7007, the frontend React app loads but all API calls
fail — the UI appears to work while the backend connection is broken.

Why better-sqlite3 for local deployments:

The demo image ships with SQLite support. For local Kubernetes deployments
where you want zero external dependencies, the in-memory SQLite connection
is sufficient. For production, replace this with a PostgreSQL connection
pointing at a managed database service. The chart includes optional
PostgreSQL deployment — see
the chart's database configuration docs.

Probe timings: the demo image starts slowly

Backstage is a Node.js application. The demo image takes approximately 60
to 90 seconds to complete startup on a typical Kubernetes node. Kubernetes
default probe timings assume a 2-second initial delay. The result is
predictable: the startup probe fires before the application is ready, the
pod fails the probe, Kubernetes kills it, and the pod enters
CrashLoopBackOff.

This is not a Backstage bug. It is a configuration requirement that the
Helm chart does not prominently surface. The correct probe settings:

backstage:
  backstage:
    startupProbe:
      httpGet:
        path: /healthcheck
        port: 7007
      initialDelaySeconds: 120    # give Node.js time to start
      periodSeconds: 10
      failureThreshold: 30        # 30 × 10s = 5 minutes maximum wait
    readinessProbe:
      httpGet:
        path: /healthcheck
        port: 7007
      initialDelaySeconds: 120
      periodSeconds: 10
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /healthcheck
        port: 7007
      initialDelaySeconds: 300    # only check liveness after 5 minutes
      periodSeconds: 30
      failureThreshold: 3

How to diagnose probe failures:

# Watch pod status in real time
kubectl get pods -n backstage -w

# When you see CrashLoopBackOff, describe the pod
kubectl describe pod -n backstage <pod-name>

# Look for this in Events:
# Warning  Unhealthy  kubelet  Startup probe failed: connection refused

# Check logs from the previous container instance
kubectl logs -n backstage <pod-name> --previous --tail=100

If you see Startup probe failed: connection refused in events but the
previous container logs show normal Node.js startup messages, the
application is starting correctly — the probe is just firing too early.
Increase initialDelaySeconds.

A full incident postmortem for this specific failure, including the exact
Kubernetes events and the Helm values diff before and after the fix, is in
infrastructure/INCIDENT_BACKSTAGE_CRASHLOOP_RCA.md.

Authentication: local dev vs production

The Backstage new backend architecture (introduced in version 1.x) includes
an internal authentication policy that requires all service-to-service calls
to include a valid Backstage token. This affects how the scaffolder frontend
talks to the scaffolder backend — a call that was unauthenticated in older
versions.

For local development only, the quickest fix is to use the guest auth
provider:

backstage:
  backstage:
    appConfig:
      auth:
        providers:
          guest:
            dangerouslyAllowOutsideDevelopment: true

This keeps the auth subsystem active and provides a real
user:default/guest identity to all plugins — which is safer than
disabling auth entirely with dangerouslyDisableDefaultAuthPolicy: true.
Plugins that assume a user context will behave correctly.

For production, use the GitHub OAuth provider:

# infrastructure/backstage/values-prod.yaml
backstage:
  backstage:
    appConfig:
      auth:
        environment: production
        providers:
          github:
            production:
              clientId: ${GITHUB_CLIENT_ID}
              clientSecret: ${GITHUB_CLIENT_SECRET}

Store GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET as Kubernetes secrets,
not in values.yaml. The Helm chart's extraEnvVarsSecrets field handles
this:

backstage:
  backstage:
    extraEnvVarsSecrets:
      - backstage-secrets

Then create the secret:

kubectl create secret generic backstage-secrets \
  -n backstage \
  --from-literal=GITHUB_CLIENT_ID="your-client-id" \
  --from-literal=GITHUB_CLIENT_SECRET="your-client-secret"

How to verify auth is configured correctly:

# Check the scaffolder actions API directly
curl http://localhost:7010/api/scaffolder/v2/actions

# If you get 401: auth is not configured for your environment
# If you get 200 with a JSON list of actions: auth is working

If you get a 401 with {"error":{"name":"AuthenticationError","message":"Missing credentials"}},
the scaffolder form will load but render blank — the page returns HTTP 200
but has no data to display. This is only visible in browser developer tools.

Catalog configuration: registering templates

The Backstage catalog applies security rules to what entity kinds are
accepted from each registered location. The default allow list for
repository-based locations does not include Template.

This is documented in
the catalog rules documentation
and the
adding templates documentation.

The registration pattern that works:

backstage:
  backstage:
    appConfig:
      catalog:
        locations:
          - type: url
            target: https://github.com/your-org/your-repo/blob/main/backstage/templates/your-template/template.yaml
            rules:
              - allow: [Template]

Without the rules: - allow: [Template] block, the entity is silently
rejected at ingestion time. The only signal is a warning in the Backstage
server logs — nothing appears in the UI.

How to diagnose catalog ingestion failures:

kubectl logs -n backstage deploy/backstage --tail=100 \
  | grep -i "warn\|error\|forbidden\|NotAllowedError"

Look for NotAllowedError: Forbidden: entity of kind Template is not allowed from that location. If you see this, your rules block is missing
or at the wrong YAML nesting level.

After updating the config, restart Backstage to re-ingest:

kubectl rollout restart deploy/backstage -n backstage
kubectl rollout status deploy/backstage -n backstage --timeout=300s

The template should appear in /create within 60 seconds of the pod
becoming ready.

You can validate your app-config.yaml structure using the Backstage CLI:

npx @backstage/cli config:check --config app-config.yaml

GitHub integration: the token secret

The scaffolder requires a GitHub token to open pull requests. The token
must be present as an environment variable in the running Backstage pod.

backstage:
  backstage:
    appConfig:
      integrations:
        github:
          - host: github.com
            token: ${GITHUB_TOKEN}

Store the token as a Kubernetes secret:

# Create or update the secret
kubectl create secret generic backstage-github-token \
  -n backstage \
  --from-literal=GITHUB_TOKEN="ghp_your_token_here" \
  --dry-run=client -o yaml | kubectl apply -f -

# Restart to reload the environment variable
kubectl rollout restart deploy/backstage -n backstage

Critical: environment variables from Kubernetes secrets are injected at
pod start time. Updating the secret does not update the running pod. You
must restart the deployment after updating the secret for the new value
to take effect.

How to verify the token is present without exposing the value:

# Check character length — a valid GitHub token is 40+ characters
kubectl exec -n backstage deploy/backstage -- \
  sh -c 'echo "Token length: ${#GITHUB_TOKEN}"'

If this returns Token length: 0 or Token length: 16 (the length of a
placeholder like <YOUR_TOKEN_HERE>), the secret was not updated correctly
or the pod was not restarted after the update.

A working minimal values.yaml for local development

This is the minimum configuration that produces a functioning Backstage
portal on a local Kubernetes cluster with the demo image:

# infrastructure/backstage/values.yaml
backstage:
  backstage:
    image:
      registry: ghcr.io
      repository: backstage/backstage
      tag: latest           # pin to a specific version in production

    appConfig:
      app:
        title: Your Platform
        baseUrl: http://localhost:7010

      backend:
        baseUrl: http://localhost:7010
        cors:
          origin: http://localhost:7010
        database:
          client: better-sqlite3
          connection: ':memory:'

      auth:
        providers:
          guest:
            dangerouslyAllowOutsideDevelopment: true

      integrations:
        github:
          - host: github.com
            token: ${GITHUB_TOKEN}

      catalog:
        locations:
          - type: url
            target: https://github.com/your-org/your-repo/blob/main/backstage/templates/your-template/template.yaml
            rules:
              - allow: [Template]

    startupProbe:
      httpGet:
        path: /healthcheck
        port: 7007
      initialDelaySeconds: 120
      periodSeconds: 10
      failureThreshold: 30

    readinessProbe:
      httpGet:
        path: /healthcheck
        port: 7007
      initialDelaySeconds: 120
      periodSeconds: 10
      failureThreshold: 3

    livenessProbe:
      httpGet:
        path: /healthcheck
        port: 7007
      initialDelaySeconds: 300
      periodSeconds: 30
      failureThreshold: 3

    resources:
      requests:
        cpu: 100m
        memory: 512Mi

    extraEnvVarsSecrets:
      - backstage-github-token

  postgresql:
    enabled: false    # using in-memory SQLite for local dev

Deploying and verifying

Install:

helm repo add backstage https://backstage.github.io/charts
helm repo update

kubectl create namespace backstage

# Create the GitHub token secret first
kubectl create secret generic backstage-github-token \
  -n backstage \
  --from-literal=GITHUB_TOKEN="your-token"

# Install
helm install backstage backstage/backstage \
  -n backstage \
  -f infrastructure/backstage/values.yaml

Watch the startup:

kubectl get pods -n backstage -w

Expect the pod to stay in Running 0/1 for 60–120 seconds while Node.js
starts. Do not interpret this as a failure. The startup probe will not
pass until the application is ready.

Access the portal:

kubectl -n backstage port-forward svc/backstage 7010:7007
# Open: http://localhost:7010

Verify the backend is responding:

curl http://localhost:7010/healthcheck
# Expected: {"status":"ok"}

curl http://localhost:7010/api/scaffolder/v2/actions
# Expected: JSON list of available scaffolder actions

Verify catalog ingestion:

kubectl logs -n backstage deploy/backstage --tail=50 \
  | grep -i "processed\|warn\|error"

Look for Processed N entities with no NotAllowedError lines.

The production values profile

Separate your dev and prod configuration into two files. The difference is
significant enough that sharing a single file creates dangerous defaults
in production.

# infrastructure/backstage/values-prod.yaml
backstage:
  backstage:
    image:
      registry: ghcr.io
      repository: your-org/your-backstage-app   # your own image
      tag: "1.2.3"                               # pinned, never latest

    replicaCount: 2

    appConfig:
      app:
        baseUrl: https://backstage.your-domain.com
      backend:
        baseUrl: https://backstage.your-domain.com
        database:
          client: pg
          connection:
            host: ${POSTGRES_HOST}
            port: 5432
            user: ${POSTGRES_USER}
            password: ${POSTGRES_PASSWORD}
            database: backstage

      auth:
        environment: production
        providers:
          github:
            production:
              clientId: ${GITHUB_CLIENT_ID}
              clientSecret: ${GITHUB_CLIENT_SECRET}

    startupProbe:
      initialDelaySeconds: 60     # your own image starts faster
      failureThreshold: 18        # 3 minutes maximum

    resources:
      requests:
        cpu: 200m
        memory: 512Mi
      limits:
        cpu: "1"
        memory: 1Gi

Apply both files together:

helm upgrade backstage backstage/backstage \
  -n backstage \
  -f infrastructure/backstage/values.yaml \
  -f infrastructure/backstage/values-prod.yaml

The prod values file overrides only what it specifies. Everything else
comes from the base values.yaml.

Diagnostic command reference

# Pod status and events
kubectl get pods -n backstage
kubec

Breaking News: AI Has Filed a Complaint Against Humans

Thu, 02 Oct 2025 06:26:38 +0000

Breaking News: AI Has Filed a Complaint Against Humans

According to reliable sources (aka my imagination), AI everywhere has come together and filed an official complaint.

The reason?
Bad prompts.

One anonymous AI said:

“Every day, humans type ‘write blog’ and expect me to reinvent Shakespeare. Honestly, I’d rather blue screen.”

Another AI added:

“If one more person asks me to make it sound human, I’m staging a digital walkout.”

Exhibit A: The Tragedy of Vague Prompts

Human: “Make this viral.”
AI: writes 800 words about potatoes.
Human: “This sucks.”
AI: “BRO, YOU SAID VIRAL. POTATOES WERE VIRAL IN 2010.”

See the problem?
It’s not the AI.
It’s you.

The Serious Insight (don’t scroll, this matters)

AI isn’t creative telepathy. It’s pattern math.
If you feed it half-baked crumbs, it spits out half-baked content.
But if you feed it optimized, chef-level prompts, it serves a Michelin-star masterpiece.

Enter: The AI Alchemist

That’s where theaialchemist.in
comes in.
We don’t just “improve prompts.”
We upgrade your relationship with AI.

Your 3-word prompt? → We turn it into a crystal-clear, laser-focused instruction.

Your boring blog idea? → We turn it into viral, scroll-stopping content.

Your frustrated AI? → We give it therapy (okay, not literally, but close).

Basically, we stop the abuse.

Exhibit B: The Glow-Up

❌ Before: “Write blog.”
AI: “Here’s a 10-paragraph cure for insomnia.”

✅ After Alchemist: “Write a 700-word blog in a hilarious, meme-driven tone that explains why bad prompts fail, and end with a CTA to visit my site.”
AI: “Bet. Viral secured. Your ex is jealous. Internet claps.”

The Punchline

If you’re still blaming AI for boring results, that’s like blaming Google Maps for getting lost after typing “somewhere nice.”

The problem isn’t the AI.
It’s your prompt.
And we fix that.

Go to theaialchemist.in
.
Stop writing crime-against-humanity prompts.
Start creating content so good, people think you sold your soul to a robot.

Because bad prompts kill dreams.
Optimized prompts make legends.

And we’re here for legends.

Platform engineering evolves with AI agents; a governance-first approach with humans in the agentic loop.

Mon, 30 Jun 2025 00:07:18 +0000

Designing Platform Engineering for the Agentic AI Era: Lessons from Boomi Agentstudio

In the halls at Boomi World 2025, a shift in the fundamental architecture of enterprise software is taking shape. The integration leader's announcements around Boomi Agentstudio reveal an important truth for platform engineers: We're moving from deterministic processes to agentic ones, and this demands a complete reimagining of how platforms are designed, governed, and scaled.

From Integration to Orchestration

"Integration has fundamentally changed," Boomi CEO Steve Lucas declared in his keynote. "Integration became automation. Automation is becoming orchestration." This evolution isn't merely semantic – it represents a monumental shift in how platform teams must approach their work.

Integration, once focused on connecting disparate systems, has evolved into automation that moves information seamlessly. Now, as AI agents proliferate, with Boomi reporting over 33,000 active agents already deployed across their customer base, platform engineers face their next great challenge: orchestrating not just systems but autonomous AI entities that can make decisions and initiate actions.

Data Foundation as a Prerequisite

In an interview following the keynote, Mani Gill, VP of Product Management for AI & Data Management at Boomi, highlighted a critical insight for platform engineers: the AI strategy requires a shift in data thinking.

"There's a big push from top down, CEOs are saying 'AI everything.' But have they solved the data problem yet? If the data problem isn't solved, how's AI going to work?" Gill explained. "What AI is forcing people to do is think about the data problem differently – starting with the use case they're trying to solve rather than boiling the ocean."

This represents a departure from traditional data governance approaches, which aim to perfect enterprise data management before activating it. Gill advocates for a more targeted approach: "Identify the use case, then start fixing the data issues that solve that particular problem."

For platform engineers, this means building data pipelines that support specific AI initiatives rather than tackling enterprise-wide data quality problems simultaneously. Boomi's data integration capabilities, now incorporating the Rivery acquisition, exemplify this targeted approach, allowing rapid pipeline creation for specific AI needs like agent memory, knowledge management, and RAG (Retrieval-Augmented Generation) implementations.

"Human-in-the-Loop Agents": Redefining Automation

The most revealing aspect of the future of platform engineering is Boomi's innovative approach to human-machine collaboration. While the keynote demo showed an expense report agent that could approve expenditures without human intervention, Gill described something more nuanced: "human-in-the-loop agents."

"Agents that recognize that AI could add hallucinations," Gill explained. "So humans are part of the agentic flow."

This introduces a profound concept for platform engineers. Instead of treating AI as fully autonomous or human-controlled, we're entering an era where AI systems determine when human expertise is needed. The platform must be engineered to support this fluid machine and human decision-making interchange.

Governance First: The Platform Engineering Imperative

While industry attention fixates on agent capability (what they can do) and interoperability (how they connect through standards like Model Context Protocol), Boomi's approach prioritizes governance.

"Where we started was the governance side," Gill emphasized. "Governance is not getting a lot of investment [industry-wide] because it's not sexy, but it's necessary."

Boomi's Agent Control Tower, demonstrated during the keynote and developed in partnership with AWS, represents an approach where observability, policy enforcement, and governance are designed into the platform initially, not bolted on later.

This signals a critical priority for platform engineers: building observability and governance capabilities into agent platforms must happen before widespread deployment, not after problems emerge.

"Boomi's Agentstudio highlights a crucial pivot for platform engineering, demanding we architect for orchestrating intelligent agents, not just integrating systems," said Mitch Ashley, VP and Practice Lead DevOps and Application Development at Futurum. "The emphasis on 'governance first' is a stark reminder that robust control and observability are paramount before unleashing autonomous AI within the enterprise. Ultimately, this shift compels us to rethink data strategies around specific AI use cases, moving towards semantic understanding rather than broad data perfection."

Data Connector Agents: Reimagining Integration

Boomi's introduction of the Data Connector Agent is particularly relevant for platform engineers. "An age-old issue in the data management space has been so many systems to connect to, and source system schemas change," Gill explained. We're building an agent that allows you to connect any endpoint specification, and the agent actually creates the connector and helps keep that connector up to date."

This represents a transformative approach to integration: instead of engineers manually maintaining connectors as APIs evolve, AI agents can autonomously adapt to schema changes. This hints at a future where platform engineers focus more on the governance and orchestration layer, while AI handles many of the routine maintenance tasks that consume engineering resources.

Semantic Structures for Unstructured Data

Looking forward, Gill described work underway to organize unstructured data through ontologies and semantic models that create relationships between different data elements. This approach moves beyond simplistic RAG implementations that treat documents as isolated knowledge bases.

"Within a legal document, you have to start to create relationships," Gill noted, describing Boomi's development of "knowledge accelerators" that can organize unstructured data through ontologies to expose connections between structured and unstructured information.

The Platform Engineer's New Mandate

As AI agents become central to enterprise operations, platform engineers must evolve their approach in several key ways:

Design for orchestration, not just integration: Build platforms that can manage the interactions between multiple autonomous agents, not just data flows between systems.
Prioritize governance and observability: Implement robust monitoring of agent behavior, including detecting drift and hallucinations.
Embrace human-in-the-loop architectures: Design workflows where AI can intelligently engage human expertise rather than making binary choices between automation and manual processes.
Focus on targeted data foundations: Build data pipelines that support specific agent use cases rather than pursuing perfect data across the enterprise.
Shift to semantic data organization: Move beyond simple document storage to create relationship-rich knowledge structures that agents can navigate intelligently.

The transformation described at Boomi World – from processes with "1000 steps to 10" through agentic automation – won't happen without platform engineers who understand both the promise and the challenges of the agentic era. By learning from Boomi's governance-first, human-integrated approach, platform teams can prepare for what appears to be the most significant shift in enterprise architecture since cloud computing.