AI-native SDLC with Autonomous Agents

An architectural design and proof of concept for a secure, scalable AI-native software development lifecycle (SDLC). I scope issues with a coding agent on my laptop, then hand them to autonomous agents running in isolated, disposable containers on Kubernetes.

View source

01 · Use Case

Why Autonomous Agents in the Cloud?

On 14 July 2026, I found Claude Code exploring my computer outside the repository I had given it. When an agent is missing context, it gets resourceful. Technically, it can walk up your file tree and into ~/.ssh.

A clearer prompt and sandbox mode help. But neither is a boundary: by default, sandboxes limit what an agent can write, not what it can read.

Agents Can Read Beyond the Repository

A clearer prompt and sandbox mode help. But neither is a boundary: by default, sandboxes limit what an agent can write, not what it can read.

Using Dev Containers to Restrict File System Access

Zed, my IDE of choice, supports dev containers, so I added a hard boundary without changing how I work.

My per-project devcontainer.json mounts only two things:

The repository, at the same path as on my laptop. Nothing else from the host is visible.
Claude's memory directory (~/.claude). Because the repository path is mirrored, the agent finds its project memory and keeps learnings between sessions.

{
  "name": "Claude Node Sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "workspaceMount": "source=${localWorkspaceFolder},target=/Users/username/Workspace/path/to/project,type=bind,consistency=cached",
  "workspaceFolder": "/Users/username/Workspace/path/to/project",
  "mounts": [
    "source=${localEnv:HOME}/.claude,target=/home/node/.claude,type=bind,consistency=cached"
  ]
}

This worked for a while… but did not scale.

02 · Architecture

Kubernetes Architecture

High-Level Architecture

The numbered steps follow one workflow run from issue to pull request. The proof of concept runs on Azure, but the design is cloud-agnostic, so supporting services are labeled generically (for example, object storage). Cloud Building Blocks below maps each one to AWS and Google Cloud.

Workflow Sequence

GitHub sends a webhook to the workflow service when an issue is ready.
The workflow service submits a run to Argo Workflows.
Argo Workflows runs each step as an agent pod.
The agent requests a scoped GitHub token from the broker.
The agent calls models through the AI gateway.
The agent pushes commits and comments on GitHub.
The agent updates status and stores artifacts through the platform services.

Platform services authenticate to Azure with workload identity. Agent pods have no cloud identity: they get a short-lived GitHub token from the broker and reach Azure only through the platform services. Steps 3–7 repeat for each agent in the loop.

Short-Lived Credentials for Cloud and GitHub

Nothing in the cluster holds a long-lived secret. Kubernetes issues every workload a short-lived token tied to its ServiceAccount, and each side exchanges it differently:

Platform services exchange it with the cloud's identity provider for access to cloud resources. Implementations differ by provider. On Azure, this is Microsoft Entra Workload ID.
Agent pods get no cloud identity. The GitHub token broker exchanges their token for a GitHub token scoped to the pod's role and one repository.

Same Kubernetes identity, two exchanges. Every token expires. Pods never name the repository: the broker looks it up, so a pod can't ask for access to another one.

These credentials cover access to the cloud and GitHub only. When agents call the platform services, for status and artifacts, they use HMAC tokens (design re-used from my Tally Split AI project) scoped to their workflow run.

GitHub Access per Agent Role

Each role is limited to one repository.

Role	Access to its one repository
`planner`	read code, write issues
`coder`	write code
`reviewer`	read code, comment on pull requests
pull request step	open pull requests

One Kubernetes token per workload, exchanged for cloud or GitHub access.

The platform runs in one virtual network. Agent egress is controlled, and every supporting service is network-integrated with the cluster.

Capability	Azure	AWS	Google Cloud
Managed KubernetesRuns the platform services, Argo Workflows and one pod per agent task.	Azure Kubernetes Service (AKS)	Amazon EKS	Google Kubernetes Engine (GKE)
Virtual networkOne network boundary for the cluster and its supporting services.	VNet	VPC	VPC
Network integrationConnects supporting services over the provider's backbone, through public or private endpoints.	Service endpointsPrivate Endpoints	Gateway endpointsPrivateLink interface endpoints	Private Google AccessPrivate Service Connect
Egress controlLimits where agents can send data.	Azure Firewall	AWS Network Firewall	Cloud Next Generation Firewall
Workload identityPlatform services reach the database, storage and secrets without stored credentials. Agent pods get none.	Microsoft Entra Workload ID	EKS Pod Identity	Workload Identity Federation for GKE
SecretsCentralized secret management and governance, following the provider's best practices.	Azure Key Vault	AWS Secrets Manager	Secret Manager
Container registryAgent images pulled close to the nodes.	Azure Container Registry	Amazon ECR	Artifact Registry
Platform databaseSystem of record for runs, retries and cost.	Azure Database for PostgreSQL	Amazon RDS for PostgreSQL	Cloud SQL for PostgreSQL
Object storageArtifacts each run produces, stored outside the cluster.	Azure Blob Storage	Amazon S3	Cloud Storage
Model accessModel calls through a managed, network-integrated endpoint.	Azure API Management AI gateway	Amazon Bedrock	Vertex AI

note

Pod Startup in Seconds Requires Network Integration

Network integration keeps traffic on the provider's backbone instead of crossing the public internet, an extra hop that adds latency. Every task starts a new pod, and we want it ready in a few seconds, not a few minutes.

Decided

Agents in the SDLC sit upstream of every release, so a careless or compromised agent has a wide blast radius. That is why this platform builds in isolation, least privilege and scale from day one instead of hardening later.

Decision	Why	Trade-off
01 Argo Workflows over a code-first engine	Every step is a container, so each agent gets its own image, tools, credentials and model. Argo runs that natively as a declarative DAG on Kubernetes, and it's a CNCF graduated project.	Loops are declared up front and must be bounded. Code-first engines like Temporal or Dapr Workflows allow open-ended logic, but each step is a function, not a container.
02 Agents use scoped HMAC tokens, not cloud identities	Each agent gets a signed HMAC token, scoped to its workflow run, resource and actions. Platform services hold the cloud access and check every request against the token.	Every cloud access goes through a platform service API, so each new capability needs an endpoint.
03 One agents namespace, one ServiceAccount per role	No per-role secrets live in the cluster, so roles don't need separate namespaces. Namespaces stay free for tenancy, per team or client.	Only Argo may create pods in the agents namespace, enforced with RBAC. Otherwise any pod could claim any role.
04 GitHub token broker instead of tokens in a cloud vault	Pulling from a vault needs a cloud identity per pod, and vaults aren't built for one secret per run. The broker trusts the pod's own Kubernetes token and reads the repository from pod metadata, so cross-repository requests are denied by construction.	One more service on the critical path: if it's down, no agent starts. Runs with replicas.
05 Workflow service is the system of record	Runs, retries and cost live in PostgreSQL. Argo only orchestrates, which keeps its objects small and well under the 1 MB etcd limit.	Two views of run status, kept in sync by step 7.
06 Skills baked into the agent image	No network calls at startup, no version drift during a run.	A skill change means an image rebuild.
07 GitHub webhook goes straight to the workflow service	One event source doesn't need an event-routing layer.	Each new event source means code in the workflow service. Revisit with Argo Events when more sources arrive.
08 One PostgreSQL server, separate databases and users	One server to run and pay for. Workflow data and Argo data stay separate.	Argo connects with a stored password, kept in its own namespace.

Interim Choices

Deliberate choices to get the proof of concept running quickly, each with an intended production path.

Choice	Why	Production path
09 Vercel AI Gateway for model access	Purely to ship the proof of concept fast: existing credits and setup in minutes.	The cloud provider's network-integrated model gateway.
10 No egress firewall	A managed firewall is a fixed monthly cost that a proof of concept doesn't justify. The network is designed to add one.	Route agent egress through the firewall and allow only GitHub, the model gateway and package registries.

03 · Requirements

Features of an AI-native SDLC Platform

Coding agents are everywhere, yet measured productivity gains have been modest. The next order of magnitude doesn't come from more agents on more laptops. It needs a platform that's customizable for a team's specific workflow.

Infrastructure
Scale
Challenge
A laptop runs 4–5 sessions, and subscription-based harnesses in VMs scale per seat, not per task.
Solution
Kubernetes schedules one pod per task on node pools that grow with demand, orders of magnitude beyond a laptop.
Infrastructure
Reliability
Challenge
VMs and stateful runners pin each session to one machine, so a failed host takes the work down with it.
Solution
Battle-tested Kubernetes primitives: failed containers restart, pods reschedule onto healthy nodes, and Jobs retry with a backoff limit.
Security
Isolation
Challenge
Agents read beyond the repository they work on.
Solution
One clean container per task, with only the repository mounted.
Security
Least privilege
Challenge
Agents run with a developer's long-lived credentials.
Solution
A token broker issues each agent a short-lived GitHub token, downscoped to its role and one repository. Agents hold no cloud credentials.
Data
State
Challenge
Retries and intermediate output flood issues and pull requests.
Solution
A dedicated system of record, an artifact service plus database, tracks starts, retries and runtime. GitHub only sees the result.
Interoperability
Harness-agnostic
Challenge
The platform gets locked to one coding agent.
Solution
Goose as one unified interface: model providers via API, or Claude Code and Codex via ACP, with the same extensions passed as MCP servers.
Platform
Extensibility
Challenge
Each team or client needs a different coding loop, and hard-coded pipelines get rebuilt every time.
Solution
Declarative Argo workflows define each loop in YAML from shared templates, and the cloud-native ecosystem adds eventing, policy and observability without custom glue.
Governance
Foundation Backed Open Source
Challenge
Vendor lock-in and licensing risk.
Solution
Built on CNCF and AAIF projects, which reduces risk of building a product on top of these projects.
FinOps
Cost efficiency
Challenge
Sub-agents inherit the parent session's flagship model, at least twice the price of a mid-tier model.
Solution
Models sized to the task, with token usage recorded per task to estimate cost.

A platform lets each kind of work run its own loop: a bug fix on a mid-tier model, a spike or proof of concept on a flagship. It also lets an organization standardize proven loops and improve them across teams, which is how quality stays consistent at scale.

Footnotes

Research Studies on AI & Developer Productivity
- METR: Joel Becker, Nate Rush, Beth Barnes, and David Rein (July 2025): experienced open-source developers took 19% longer with AI tools, while believing they were 20% faster.
- CEPR VoxEU: Demirer, Musolff and Yang (June 2026): across more than 100,000 GitHub developers, autonomous coding agents nearly tripled commits, but shipped releases rose only ~30%.
Flagship versus mid-tier list prices per million tokens (input / output)
Provider Flagship Mid-tier Gap
Anthropic Opus 5.5
$4 / $20 Sonnet 5.5
$2 / $10 2x
OpenAI GPT-6 Astra
$10 / $50 GPT-6.1 Sol
$2 / $10 5x
Prices fetched 10 October 2026.

Provider	Flagship	Mid-tier	Gap
Anthropic	Opus 5.5 $4 / $20	Sonnet 5.5 $2 / $10	2x
OpenAI	GPT-6 Astra $10 / $50	GPT-6.1 Sol $2 / $10	5x

04 · Workflow

Any Bounded Loop Maps to a DAG

Each use case designs its own coding loop. The platform needs only one property: every retry has a limit, so the loop unrolls into a finite chain of steps, a directed acyclic graph (DAG).

Each iteration runs as a new step with its own pod, so the declared graph never cycles back.

Why Argo Workflows

Every step is a container, so each agent in this multi-agent loop (planner, coder, reviewer) gets its own image, tools, credentials and model. Argo Workflows runs that natively as a DAG on Kubernetes, and it's a CNCF graduated project.

Every step runs the same agent image in its own pod, with the role passed as a parameter.

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: coding-loop
spec:
  entrypoint: main
  arguments:
    parameters:
      - name: issue # GitHub issue number
  templates:
    - name: main
      # Note: Argo syntax uses lists of lists, hence `- -`
      steps:
        - - name: plan
            template: agent
            arguments:
              parameters: [{ name: role, value: planner }]
        - - name: build
            template: implement-and-review
            arguments:
              parameters: [{ name: attempt, value: "1" }]
        - - name: open-pr
            template: open-pr

    # The loop: a template that calls itself, bounded by `attempt`
    - name: implement-and-review
      inputs:
        parameters: [{ name: attempt }]
      steps:
        - - name: implement
            template: agent
            arguments:
              parameters: [{ name: role, value: developer }]
        - - name: review
            template: agent
            arguments:
              parameters: [{ name: role, value: reviewer }]
        - - name: retry
            template: implement-and-review
            when: "'{{steps.review.outputs.parameters.verdict}}' == 'changes' && {{inputs.parameters.attempt}} < 2"
            arguments:
              parameters:
                - name: attempt
                  value: "{{=asInt(inputs.parameters.attempt) + 1}}"

    # One container image, one pod per step, role set by parameter
    - name: agent
      inputs:
        parameters: [{ name: role }]
      outputs:
        parameters:
          - name: verdict
            valueFrom: { path: /tmp/verdict, default: none }
      retryStrategy: { limit: 2 } # infrastructure retries, not review rounds
      activeDeadlineSeconds: 3600
      container:
        image: registry.example.com/agents/goose:1.0
        args: [--role, "{{inputs.parameters.role}}", --issue, "{{workflow.parameters.issue}}"]

    - name: open-pr
      container:
        image: registry.example.com/tools/open-pr:1.0
        args: [--issue, "{{workflow.parameters.issue}}"]

What's Next?

In 2026 I left Microsoft to learn AI engineering hands-on. After the ByteByte AI bootcamp, I built my own AI apps, including AKS Architect AI and Tally Split AI, and worked with coding agents every day. That's where I hit the limits this page addresses: my attention became the bottleneck, and agents on my own computer were a security risk.

Watch Me Build

I'm rebuilding this platform from scratch in the open, on my blog and on YouTube.

Follow me on YouTube

Want to Work Together?

I'm looking for my next role and team: complex platform and AI engineering challenges, hybrid or on-site in Munich.

Schedule a Call Email Me

AI-native SDLC with Autonomous Agents

Why Autonomous Agents in the Cloud?

Agents Can Read Beyond the Repository

Using Dev Containers to Restrict File System Access

Unable to Scale Beyond 24 GB and 4–5 Parallel Sessions

Pair Locally, Delegate to the Cloud

Kubernetes Architecture

High-Level Architecture

Workflow Sequence

Short-Lived Credentials for Cloud and GitHub

GitHub Access per Agent Role

Decided

Interim Choices

Features of an AI-native SDLC Platform

Scale

Reliability

Isolation

Least privilege

State

Harness-agnostic

Extensibility

Foundation Backed Open Source

Cost efficiency

Any Bounded Loop Maps to a DAG

Why Argo Workflows

What's Next?

Watch Me Build

Want to Work Together?