My Agents Don't Stop When I Close My Laptop

I run a fleet of AI coding agents from a browser tab — on customer calls, from my phone, from a hotel lobby. When I close my laptop, they keep working. This post is about how I built that on Amazon Bedrock AgentCore , and what it means for infrastructure engineers in an AI-native world.

For the first part of my career, I was a network engineer and system administrator. I worked for a telecom and for small and medium business managed service operators, building, designing, implementing, troubleshooting, and securing networks and the compute infrastructure that powers applications and developers. Not writing the applications. Making sure the platform was solid enough that applications could run.

Here's what I keep thinking about: as AI agents get better at writing code, the engineers who understand the platform, the network, the security boundary, the compute layer, the identity plane, are going to become more valuable, not less. Agents can write code, even build full applications end to end. They can't, at least today, architect how it fits into your environment, who can call it, how it scales, or what happens when it fails. That's still mostly a human job.

This post is about something I built that illustrates exactly that point. The AWS team wrote a great technical deep-dive on how remote coding agents work on AgentCore — I'd start there if you want the how-it-works detail: “It’s Safe to Close Your Laptop Now” (AWS ML Blog) 

What I've built and have been experimenting with is a conversational chat interface that functions as an orchestration layer and control plane for a fleet of AI agents running in the cloud.

As an AWS Solutions Architect, I now have a fleet of personal developers available on demand. They write code, write infrastructure as code, deploy it, manage it, and operate it securely within my AWS organization. Not just any generic agent harness, but actual remote coding agents — including Claude Code and Kiro , an agentic IDE. The workspace, the tools, the identity, the memory — none of it changes between agents. That consistency is what makes this work.

Here's what that looks like in practice. I'm on a call with a customer, talking through an architecture challenge. While we're talking, I delegate one of my coding agents to start researching the problem, sketch out a design, and start building. I relay requirements through the same chat interface I'm already using. By the end of that customer call, I often have a working prototype or demo ready to show them. Not a slide. A real, deployed thing.

That's not a future state. That's what this system does today. And it doesn't stop when the call ends.

The agents keep running. From my laptop, from my phone, from a hotel lobby — anywhere I have a browser, I can open the same chat interface and pick up exactly where I left off. The fleet doesn't know or care where I am. It's always on, always ready, and the work it was doing when I stepped away is still in progress when I come back.

Beyond the coding agents, the platform includes an Orchestrator and an agent factory. The Orchestrator sits at the top of the fleet, routing each chat turn to the right specialist or answering directly. It remembers what you've been working on across sessions.

The factory lets you spin up new agents from a plain chat prompt. Describe what you want. The Orchestrator drafts a plan, shows it to you, asks for approval, and deploys a new runtime. The new agent shows up in the model picker, ready to go.

All of this is secured and governed by the per-user identity vault provided by Amazon Bedrock AgentCore. Identity, policy, and the permissions agents can act under are all things I, as an operator, explicitly grant. Each agent acts on my behalf within external tools and systems — assuming only my identity.

Chat UI | Open WebUI , Amazon ECS Fargate , Amazon Cognito 

Agent runtime | Amazon Bedrock AgentCore Runtime  — see also: Building a Multi-Agent AWS Platform with Amazon Bedrock AgentCore Part 1 

Tools | Amazon Bedrock AgentCore Gateway 

Identity | Amazon Bedrock AgentCore Identity  — user credentials end to end

Memory + Storage | Amazon Bedrock AgentCore Memory  + Amazon S3  — see also: Building Memory-Enabled AI Agents with Amazon Bedrock AgentCore 

Open WebUI is the front door. Users log in with SSO, pick an agent, and start chatting. Behind that is a persistent microVM that survives between sessions. The agent has tools, memory, and a shared filesystem.

Every tool call is authorized under the identity of the person who triggered it. Not a shared service account. Your credentials travel end to end.

The people who built the internet — the network engineers, the data center operators, platform engineers and security teams — understood something: the connections between things matter as much as the things themselves.

The infrastructure and how it operates, scales, and evolves is fundamental to the applications and business functions that run on top of it. AI agents are no different; they need that same foundation to operate within.

That knowledge is suddenly extremely relevant again.

As code becomes something agents generate on demand, the work that remains is exactly the work infrastructure engineers have always done: making sure everything is connected correctly, secured properly, scaled appropriately, and observable when something goes wrong. The difference is that now you're building infrastructure for a fleet of AI agents instead of a fleet of VMs.

If you're curious how Amazon Bedrock AgentCore compares to building agent infrastructure yourself, Choosing between Managed vs Modular AI Agents  is a good read on exactly that tradeoff.

My hot take: infrastructure, security, and network engineering skills are now one of the biggest assets you can bring to AI-powered software development. If you understand how all the pieces fit together, you can build anything.

#AWS #AmazonBedrock #BedrockAgentCore #AIAgents #GenerativeAI #CloudArchitecture #SolutionsArchitect #InfrastructureEngineering #OpenWebUI

Built on Amazon Bedrock AgentCore  Runtime, Gateway, Memory, and Identity. Front-end: Open WebUI .