On 5 November 2026, Henning Teek and I showed the AWS User Group Dortmund how our AI Software Factory runs on AWS: first the model, then the implementation with AgentHub. Here are the key points, with the slides they need.

It was two talks back to back, level 400 and in English. I spoke about the software development lifecycle in the age of agents, and Henning Teek, Principal at Storm Reply, followed with AgentHub. AgentHub and our AI Software Factory are the implementation of Silicon Shoring1 on AWS, the Reply Group's AI-powered software delivery model.

Part 1: The model, the Agentic Engineering Loop

Coding agents made one part of the way from idea to release fast: writing code. Requirements, architecture decisions, review, deployment and operations still run at human speed. Speed up only the coding and you put faster code in front of the same bottleneck. That is why I did not show an agent but an operating model.

The Agentic Engineering Loop consists of loops that touch. On the outside is the customer loop with exactly two shared touchpoints: requirements at the top, acceptance at the bottom. Between them runs the engineering loop, bound to feature sets and acceptance rather than sprints. Inside it turns the agentic loop, where an agent builds, deploys and tests a single feature in minutes to hours. After go-live, the learning loop feeds incidents and usage data from operations back as new requirements. That arrow is the difference between a project and a product.

Figure 1: The Agentic Engineering Loop with customer loop, engineering loop, agentic loop and learning loop
Figure 1: The Agentic Engineering Loop. The customer is involved at two points, operations feed new requirements back. Slide from my talk, graphic: Storm Reply.

The most important habit sits in the Agentic Coding box: the agent writes no code first. It writes a specification and an implementation plan. A second model and a human review both. The human reads the plan, not the diff.

That leaves four points where a human decides: the requirements, the decisions on architecture, security and performance, the plan, and acceptance. Everything in between may run agentically, inside gates that are enforced technically. Rights that only exist in a prompt are no rights. What is not allowed must be technically impossible.

Figure 2: Four human decision points, agents work in between
Figure 2: Where humans stay in control: requirements, architecture, plan and acceptance. Slide from my talk, graphic: Storm Reply.

The full model in four zoom levels is in the article AI Software Factory: The Software Development Lifecycle in the Age of AI.

Part 2: AgentHub, an assembly line on AWS

Henning showed how this model is built. AgentHub takes requests from a web app, the terminal, GitHub, chat bots or a schedule. An agent works in an isolated sandbox and returns a Git branch or a pull request. Henning describes it as an assembly line with four stations: intake, workstation, quality gate, shipping. Agents staff the stations. Engineers design the line, set the rules and approve what ships.

Dark, lit or dimmed

The first question for any software factory is how much light it needs. In the dark factory, no human reviews a change anymore. That is cheap around the clock, but only as good as the tests, and a bad pattern spreads across many changes before anyone looks. In the lights-on factory, a human approves every step. That feels safe but runs at reviewer speed. And by the fiftieth prompt, people click yes without reading.

Henning's answer is to set the light per lane. Dependency updates, lint fixes, documentation and repairs of flaky tests run dark and merge once CI is green. Everyday features and fixes run dimmed: the agent works alone, a human reviews the pull request. Authentication, payments, data migrations and infrastructure stay lit, and a human approves the plan before the agent starts.

Figure 3: The dimmed factory with dark lane, dimmed lane and lit lane
Figure 3: The dimmed factory: autonomy follows risk and test coverage, lane by lane. Slide from Henning's talk, graphic: Storm Reply.

The lanes are not fixed. A lane gets darker when its changes have a clean track record and the tests catch their regressions. It gets lighter again as soon as something breaks in production, tests are missing or the agent enters new territory. In AgentHub the dimmer is GitHub branch protection: if a repository requires a human approval, the merge waits for a person. It is the same rule as in my part: autonomy may only go as far as verification carries.

Split trust: runtime and sandbox

Orchestration splits trust in two. The Amazon Bedrock AgentCore2 Runtime is the foreman. It takes requests over the A2A protocol, checkpoints sessions to S3 and is the only place that holds the GitHub App keys. The agent itself runs in a Lambda MicroVM, one VM per conversation, as an unprivileged user. It gets only a role that can call Bedrock and a GitHub token for a single repository that expires after one hour. Between turns the VM sleeps and wakes up with the next message. After eight hours at most it is gone.

Figure 4: AgentCore Runtime as trusted container, Lambda MicroVM as the agent's sandbox
Figure 4: The runtime holds the keys, the sandbox holds the agent. Below, one turn from start to finish. Slide from Henning's talk, graphic: Storm Reply.

The reason is prompt injection. Issues, comments, CI logs and code are written by other people, and one crafted line can tell an agent to leak a token or plant a backdoor. Henning assumes an agent will be fooled sooner or later and limits what that costs: one repository, at most one hour, and the pull request still has to pass all its checks.

Agents work through events, not chat

Instead of one big agent, several small ones work together. An issue labelled agenthub starts the Implementer, which writes code and tests and opens a pull request. The Reviewer reviews every change, the Implementer addresses the comments. After five rounds the loop stops and asks a human. A CI fixer repairs failed builds, a conflict resolver resolves merge conflicts, and an Unblocker starts issues once their blockers are done. When all checks and approvals are in place, GitHub merges automatically.

Figure 5: One job from issue to automatic merge in six steps
Figure 5: One job end to end, from a labelled issue to the merge. Slide from Henning's talk, graphic: Storm Reply.

Each of these agents is a single Markdown file. It defines who the agent is, with its own GitHub App and only the permissions it needs, and when it runs. The body of the file is the prompt. Agents are code: changes to them go through review as a pull request like everything else.

So that nobody has to watch agents work, the factory reports by itself: when an agent has a question, a check fails or the review loop hits its limit. An analytics view shows Bedrock tokens and cost per period and per initiator.

Three things to take home

  1. Dim the lights lane by lane. Autonomy follows risk and test coverage. Humans supervise the loop instead of approving every step.
  2. Split trust. The runtime holds the keys, the sandbox holds the agent. A fooled agent can do little harm.
  3. Couple agents through events. Small, specialised agents hand work over in GitHub until the job is done.

Thanks to everyone who came, and to Henning for the second part. On 19 November 2026 we show a version for people without technical background, with an open discussion, at the Agentic Shift Meetup in Dortmund.

Sources

  1. Reply: “Reply launches Silicon Shoring: an AI-Powered Software Delivery model to optimise and automate the entire Software Development Life Cycle”, press release, 15 May 2025. reply.com
  2. Amazon Web Services: “What is Amazon Bedrock AgentCore?”, Amazon Bedrock AgentCore Developer Guide, retrieved 31 October 2026. docs.aws.amazon.com