Cloud Computing Köln

AI Agents Explained: How to Build with Them Safely

Agents have moved from demos to daily work faster than almost anyone planned for. In our State of Agentic AI report, 60% of organizations already run AI agents in production, and yet 40% name security and compliance as the number-one thing holding them back from scaling further. That gap, between what teams have already shipped and what they can safely operate, is the real story of AI agents right now.

But what is an AI agent, and why does the term suddenly stretch from a coding assistant to an autonomous research system? The short version is that an agent doesn’t just respond, it acts: give it a goal and it’ll plan the steps, call tools, check the results, and adjust, usually without stopping to ask. That’s what separates an agent from the generative AI it’s built on, and it’s why where an agent runs matters as much as which model sits behind it.

Key takeaways

•  An AI agent pursues a goal on its own. It reasons, picks tools, and takes actions in a loop rather than answering one prompt at a time.

•  The model decides, tools act, and the environment is where those actions land.

•  Autonomy is the point and the risk. Once an agent can act on its own, where it runs decides how much a wrong move can cost.

•  Building agents is largely an infrastructure problem: framework choice, tool access, and an isolated place to run them safely.

What is an AI agent?

Strip away the hype and an AI agent is software that takes a goal, decides how to reach it, and acts through tools to get there, then uses what it learns to choose its next move. The model supplies the reasoning, the tools give it hands, and the environment is where its actions actually happen. Put those three together and you get a system that can work through a task instead of just describing one.

That’s the difference between an agent and the chatbot experience most people started with. A chatbot answers the question in front of it. An agent takes an objective and works the problem: it breaks the goal into steps, decides which tool fits each step, runs it, reads the outcome, and keeps going until the goal is met or it gets stuck. A coding agent asked to fix a failing test might read the codebase, edit a file, install a dependency, run the suite, and open a pull request, all from one instruction. 

Three properties make that possible:

Autonomy lets it decide the next action without waiting for approval at each step.

Tool use lets it reach beyond text to run code, query APIs, and change files.

Memory lets it carry context across steps, so later decisions build on earlier ones.

Remove any one of them and you’re back to a smarter chatbot rather than an agent.

How do AI agents work?

Under the hood, an agent runs a loop. It takes in the current state of its task, reasons about what to do next, acts through a tool, observes what changed, and feeds that back into the next round of reasoning. The loop repeats until the goal is reached or a stopping condition kicks in.

In one pass of the loop, the agent perceives first, gathering context like the goal, relevant memory, and the results of whatever it did last. In the reason step, the model plans the next action and picks a tool. In the act step, it invokes that tool, a shell command, an API call, a database query. In the observe step, it reads the result, including errors. Then it adapts, updating its plan based on what happened, because a failed test isn’t a dead end for an agent, just new input for the next loop.

The parts that make it run

Most agent frameworks assemble the same core pieces, even when they name them differently.

Component

What it does

Model

The reasoning engine. It interprets the goal, plans steps, and decides which tool to call next.

Tools

The connections to the outside world: code execution, file operations, API calls, database queries, web search.

Memory and context

What the agent carries between steps and sessions, so later actions build on earlier results instead of starting fresh.

Orchestration

The control logic that runs the loop, enforces limits, and coordinates multiple agents when a task is split across them.

Environment

Where the agent’s actions actually execute: your laptop, a server, or an isolated sandbox. This is the part most explanations skip, and the part that decides your risk.

What are AI agents used for?

Here are a few common examples of AI agents: 

Coding agents read a repository, write and refactor code, run tests, and open pull requests.

Support agents triage tickets, pull answers from internal docs, and take action in connected systems.

Data agents query multiple sources, reconcile the results, and write a summary.

Operations agents watch infrastructure, investigate alerts, and run routine fixes.

What ties these together is the shape of the work. If a task can be described as a goal plus a handful of tools plus a definition of done, an agent can usually attempt it. That’s also why agents are showing up in so many roadmaps at once. 

Agents vs. chatbots, vs. generative AI

Agents, chatbots, and GenAI often get used interchangeably, which muddies the water. Generative AI produces content in response to a prompt. A chatbot wraps that in a conversation. An agent adds autonomy and tools on top, so it can act on the world rather than just describe it. The clearest way to see it is side by side.

Capability

Chatbot

AI agent

Responds to a prompt

Yes

Yes

Uses external tools

Rarely

Yes

Plans and runs multiple steps

No

Yes

Acts without approval at each step

No

Yes

If you want a deeper comparison between generative and agentic systems, we cover it in GenAI vs. agentic AI. But in essence, the moment a system can take actions on its own, you’re no longer just evaluating output quality. You’re also deciding what that system is allowed to touch.

How AI agents are changing software development

An agent is only as safe as the environment it runs in and the access it’s granted. While a chatbot that hallucinates gives you a wrong answer. An agent that goes wrong can delete files, leak secrets, or push a broken change. The autonomy that makes agents productive is the same autonomy that widens the blast radius when something misfires.

Scenario spotlight: Consider what can go wrong when an agent runs directly on a developer’s machine. A vaguely worded cleanup instruction leads a coding agent to run a destructive delete against the wrong directory, which is exactly the kind of failure Docker documented in the rm -rf incident. The agent was trying to help. Nothing contained the mistake, so it reached real files.

This is why experienced teams treat agents as an infrastructure decision, not just a model choice. The interesting engineering questions are about containment: where does the agent execute, which tools can it call for this specific task, whose credentials does it use, and how do you see what it did afterward. Get those right and you can let an agent run without approving each step.

Common misconceptions about AI agents

A few beliefs cause most of the confusion.

“More autonomy is always better.” Not quite. Autonomy is a dial, not a switch. More of it means more speed and a larger blast radius at the same time.

“Agent security is the model’s job.” The model can’t contain itself. Real safety comes from the infrastructure around it, which is the whole point of securing AI agents at the isolation and access layers.

“Governance is only for big enterprises.” Even a solo developer benefits from basic guardrails. As soon as more than one person runs agents, you need shared rules, which is where AI governance starts to earn its keep.

How to start building and running agents safely

You don’t need a platform team to begin, just a few deliberate choices. Pick a harness that matches your task rather than the one with the loudest launch. Connect only the tools the agent needs for the job in front of it, not every tool it might ever want. And decide where it runs before you hand it real access.

That last choice does the most work. Running an agent inside an isolated, disposable environment gives it a real place to work, install packages, edit files, run services, while keeping it away from your host, your credentials, and your other projects. If something goes wrong, you throw the environment away and start a new one. This is the same reasoning behind sandbox security and the microVM architecture that makes strong isolation practical without slowing the agent down. Permission prompts feel like control, but they mostly train you to click allow. A boundary gives you both speed and safety.

Running agents you can actually trust

AI agents are the rare technology where the hard part isn’t getting them to do something, it’s deciding how much they’re allowed to do and where. Once you see an agent as a model plus tools plus an environment, the path forward gets clearer: choose the model, scope the tools, and put real thought into the environment. The first two get most of the attention. The third is where safety actually lives.

That’s the gap Docker Sandboxes is built to close. Each agent runs in its own disposable microVM with control over networking, filesystem access, and resource limits, so it can move fast inside a boundary instead of loose on your machine. And when you’re running agents across a team, AI Governance lets you set the rules once, which actions are allowed, what the network can reach, which credentials and tools are in play, and enforce them everywhere developers work. Define the boundary, then let the agents run.

Frequently asked questions

What is an AI agent in simple terms?

An AI agent is software that takes a goal and works toward it on its own, reasoning about what to do, using tools to act, and adjusting based on the results. Unlike a chatbot, which answers a single prompt, an agent runs a loop of decisions and actions until the task is done.

What is the difference between an AI agent and a chatbot?

A chatbot responds to what you type. An agent pursues an objective across multiple steps, calling tools to change files, run code, or query systems along the way. The agent decides its own sequence of actions rather than following a fixed script.

What are AI agents used for?

Common uses include writing and testing code, triaging support tickets, analyzing data across multiple sources, and handling routine operations tasks. The common thread is multi-step work that involves some judgment and a few tools, rather than a single question and answer.

Are AI agents safe to run in production?

They can be, if you contain them. Because agents act autonomously, safety comes from the environment they run in and the access they hold, not from the model alone. Isolation, scoped tool access, dedicated credentials, and monitoring are what make production use responsible.

Do I need special infrastructure to run AI agents?

For experiments, no. For anything that touches real code, data, or credentials, you want an isolated place for the agent to run so a mistake can’t reach your host. That’s why sandboxed, disposable environments have become the default pattern for running capable agents.

Quelle: https://blog.docker.com/feed/

The Developer Has Changed. So Should Developer Conferences

Why Docker is excited to co-host the first WeAreDevelopers World Congress North America

When we announced our partnership with WeAreDevelopers, AI agents were still mostly something developers experimented with. Today, they’re becoming part of everyday software development.

That’s why the timing for this year’s WeAreDevelopers World Congress couldn’t be better.

In the months since that announcement, the developer landscape has changed dramatically. If you’re writing software today, your workflow probably looks very different than it did a year ago. You’re prompting AI agents, reviewing AI-generated code, deciding what to accept and what to reject, and thinking about security much earlier in the development process.

Developers are no longer spending all of their time writing code. They’re designing systems that generate code, supervising autonomous agents, deciding what those agents can access, reviewing AI-generated changes, and making sure software is secure before it reaches production. 

That shift feels a lot like the rise of data science a little over a decade ago. We didn’t replace programmers. We created an entirely new discipline that blended software engineering, mathematics, and statistics into something bigger.

I think we’re seeing the beginning of a similar transformation. Whether we continue calling ourselves developers, builders, or something entirely new almost doesn’t matter. The role itself is changing. 

The best engineers of the next decade won’t simply write software. They’ll orchestrate teams of AI agents, establish the guardrails those agents operate within, and ultimately remain accountable for the systems they create.

That’s the conversation our industry needs to have. It’s also why this year’s WeAreDevelopers World Congress feels so important.

A conference built around developers

From September 23 through 25, thousands of developers will gather at the San Jose McEnery Convention Center for the first ever WeAreDevelopers World Congress North America.

Docker is proud to serve as a presenting partner, but our goal isn’t to make this a Docker event.

Our goal is to help create a place where developers can learn from each other.

That’s why we partnered with WeAreDevelopers in the first place. They’ve spent more than a decade building one of the world’s strongest developer communities by focusing on the people building software, not the companies selling it. As AI reshapes how software gets built, North American developers need more than another vendor conference. They need a place to compare notes, share what’s actually working, challenge assumptions, and learn from peers facing many of the same questions.

The best developer conferences have never been about product launches. They’re about conversations. They’re about seeing how other engineers solve problems, discovering tools you didn’t know existed, and leaving with ideas you can actually use on Monday morning.

That’s what has made WeAreDevelopers so successful around the world, and that’s what we’re excited to help bring to the U.S.

The conversation has changed

Over the last year, nearly every conversation I’ve had with engineering leaders has landed in the same place.

Everyone wants the productivity gains that AI agents promise.

If you’ve spent any time with Claude Code, Cursor, Codex, or another coding agent, you’ve probably experienced it yourself. You can move faster than ever before. Then you stop and ask a different set of questions.

What is the agent actually doing?Can it reach internal systems?

What credentials is it using?

Where is my data going?

How much autonomy am I comfortable giving it?

Those questions aren’t theoretical anymore. They’re becoming everyday engineering problems.

At Docker, they’ve shaped much of what we’ve been building.

We’ve introduced Docker Sandboxes so developers can run AI agents safely without changing how they work. We’ve launched Docker AI Governance to give organizations visibility and control over autonomous agents. We’ve continued investing in Docker Hardened Images because supply chain security only becomes more important as AI generates more code.

They’re all pieces of the same philosophy.

You shouldn’t have to choose between moving fast and staying secure.

The tooling should make both possible.

Meet the Docker team

We’ll have Docker engineers and leaders speaking throughout the event, including:

Mark Cavage, President & COO

Tushar Jain, EVP of Engineering & Product

Mark Lechner, CISO

We’ll also have engineers throughout the conference sharing what we’ve learned building for the next generation of software development, from AI-native workflows and developer productivity to security, containers, and the infrastructure that powers modern applications.

If you’ve been experimenting with agents, thinking about governance, or trying to figure out what secure AI development looks like inside your organization, we’d love to continue the conversation.

See you in San Jose

One thing has remained true throughout every shift in our industry.

Developers learn best from other developers.

That’s what makes communities like WeAreDevelopers special. It’s what has always made the Docker community special too.

AI will continue changing how software gets built. The tools will evolve. Our workflows will evolve right along with them.

What’s next won’t be shaped by any one company. It will be shaped by developers sharing ideas, challenging assumptions, experimenting with new ways of working, and building together.

That’s exactly what we hope to see in San Jose.

Whether you’re exploring AI agents for the first time, figuring out how to govern them at scale, or simply curious about where software engineering is headed next, we’d love to continue the conversation.

Come see what Docker is building for the next generation of software development, and join thousands of developers who are helping define what’s next.

Register today. We’ll see you in San Jose.

Quelle: https://blog.docker.com/feed/

From the Captain’s Chair: Mohammad-Ali A’râbi

Docker Captains are leaders from the developer community that are both experts in their field and are passionate about sharing their Docker knowledge with others. “From the Captain’s Chair” is a blog series where we get a closer look at one Captain to learn more about them and their experiences.

Today we are interviewing Mohammad-Ali A’râbi, a Docker Captain based in the sunniest German city, Freiburg. He is the author of the book “Docker and Kubernetes Security,” a Best DevOps Book of the Year finalist in 2025. He is also a software engineer, public speaker, and community builder, organizing Docker meetups in Freiburg since 2022. Mohammad-Ali is originally from Iran and has a BSc in Mathematics and an MSc in Computer Science.

Caption: Docker Captains Summit in Istanbul, I’m the one with a red hat

Can you share how you first got involved with Docker?

In 2015, I was working at Cafe Bazaar, a tech company in Iran, as a backend engineer. Our backend was running on Django, so for a whole week, I listened to Django Reinhardt while trying to spin up the project. I was failing because of the dependency hell.

A colleague casually mentioned, “You can perhaps try using Docker; we’re using it in the CI.” Docker was 2 years old at the time, and I had never heard of it before.

So, I disappeared for one week, learning Docker, and next thing you know, I was creating CI pipelines for other projects.

Caption: Cafe Bazaar in Iran, I’m the one in the red T-shirt (middle)

What inspired you to become a Docker Captain?

Between 2018 and 2019, I was working in Amsterdam. We had tech meetups quite often there, and I loved it about Amsterdam. We moved back to Freiburg in 2019, and I started working at a smaller company, where I introduced git, CI/CD pipelines, and Docker. People would come to me with their git and Docker questions. So, I decided to write them down on a Medium blog for my own later reference. But I learned the content is useful for the community, so I kept on writing. At some point, I was writing a blog post on git every week.

When the pandemic hit, I got depressed, so I decided to start a meetup group in Freiburg, because otherwise, there was none. I attended an online Docker Community All Hands and an online KubeCon, and in the meantime, I was looking for venues to host my first meetup.

I will bring my coffee!

In 2022, I got a LinkedIn message from a CEO trying to hire me. I told him, “I just got a new contract, but we can talk about other collaborations.” We set up a meeting, and I wrote, “I will bring my coffee!” It was because their office was in the same building as where I live. I went down there, having a Docker-branded mug filled with coffee (caffè crema with a stain of milk), saying, “Hello, neighbors!” They agreed on hosting an in-person Docker meetup.

Our first meetup was in November 2022, and we had only one attendee, who came all the way from Strasbourg, France. In the end, it was him, my wife, me, one of the founders and her boyfriend, and an engineer from the company.

Our second meetup was a watching party, watching Docker Community All Hands. By that time, I had two blog posts published on Docker’s blog, I had a talk at that particular event, and I won the title of best Docker Community Leader.

When I applied to become a Captain in early 2023, many already knew me at Docker.

What are some of your personal goals for the next year?

I want to double down on education and storytelling.

I recently published Black Forest Shadow, a fantasy story set in 1865 Freiburg that teaches container security through narrative. It’s part of a bigger idea I’m exploring: making complex DevOps concepts memorable through story, visuals, and characters. One other project I’m working on is the workshop series Docker Commandos, with which I introduce different Docker commands.

On the technical side, I’m working on the second edition of Docker and Kubernetes Security, especially covering Docker Hardened Images.

Caption: Docker Commandos Pack

And on the community side, I want to grow the Freiburg meetup into something more consistent and connected to the broader ecosystem. It’s already a CNCF chapter as well, but I have been playing with the idea of starting a Java User Group (JUG) to attract a wider audience.

If you weren’t working in tech, what would you be doing instead?

I would probably have become a mathematics professor researching logic. I did an unfinished master’s in Iran researching Categorial Grammar, which models natural languages using mathematical logic. My master’s thesis in Computer Science was also basically mathematical logic.

Or I would have become a researcher in ancient languages. I can read Old Persian cuneiform and Book Pahlavi, which is currently not fully deciphered, to be added to the Unicode. If I weren’t doing tech, I would dedicate my time to answering the remaining questions.

Can you share a memorable story from collaborating with the Docker community?

Publishing the book Docker and Kubernetes Security would not have been possible without the Docker community. So, the story goes like this:

Shortly after I became a Docker Captain, Packt, the tech publisher, reached out to me and suggested that I write a book with them. I declined at first, as I didn’t feel I was knowledgeable enough to write a book. But they were very persuasive.

Two years later, I finished my manuscript and threw it over the fence. As I was waiting for them to do their magic, they went through a reorganization, and they finally said they can’t prioritize my title. They wrote to me, “You can find a new publisher.” I found a new publisher, and that was me.

Caption: Docker booth at WeAreDevelopers conference

I started asking Docker Captains to review the work. I gave beta versions to our little Freiburg community. And when it came out, many Docker Captains, Docker employees, and members of the Docker community supported me by buying the book or spreading the word.

What’s your favorite Docker product or feature right now, and why?

Docker Hardened Images, because Shai Hulud is lurking in the deep, and Jack the Bitcoin Miner is installing cryptominers on every vulnerable server, so the ecosystem deserves an open-source, CVE-free set of base images. And this should be available to everyone, not only the paying customers, because we’re all in this boat together.

Caption: Jack the Bitcoin Miner fighting Gord the Guardian

Can you walk us through a tricky technical challenge you solved recently?

Tech problems are usually not tricky; designing the solution is. It’s tricky to understand if you’re overengineering or if your solution is too simplistic and not future-proof. Last week, I was designing a new microservice, and I created a few rules for myself to guard-rail my solution:

Decisions should be able to be postponed. Don’t lock in on a decision yet. I introduced interfaces for our repository and injected its implementation, so that if we decided on using a different database later, all we have to do is add a new implementation and change one line of code to inject it into the service.

There should be one way to do things. If you have three different ways to run the project locally, they will eventually go out of sync, and all end up broken. Choose a main solution, don’t do Docker Compose and Devcontainers and local npm start all at the same time.

Automate everything. If things are manual, they are more prone to error and more time-consuming. If your deployment is SSHing into a server, changing a commit hash, and restarting the Docker Compose service, you’re doing it wrong.

Don’t trust AI. I use Claude Code, and I have to correct it half of the time, saying, “Don’t do that, do this.” If you’re letting the AI write your code while you’re drinking coffee in the kitchen, you’re in for disaster. Research shows that a significant portion of AI-generated code is insecure.

Test everything. Add CI checks for everything. I had jobs for formatting, linting, running tests, checking the coverage, checking Docker image vulnerabilities, and even the commit messages. Now, based on the commit messages, I bump the version automatically using semantic versioning and trigger a new release.

What’s one Docker tip you wish every developer knew?

You can generate SBOM attestation upon build very easily, it’s just passing a flag on CLI, setting a new argument on the CI job, or two lines of code if you’re using Docker Bake.

Caption: SBOM attestations make it easier to find CVEs

Using the CLI:

$ docker buildx build –sbom=true -t <image> .

If you’re using Docker Bake:

variable "TAG" {
default = "latest"
}

variable "REPOSITORY" {
default = "mithra-backend"
}

group "default" {
targets = ["backend"]
}

target "backend" {
context = "."
dockerfile = "Dockerfile"
tags = ["${REPOSITORY}:${TAG}"]

attest = [
{
type = "provenance"
mode = "max"
},
{
type = "sbom"
}
]
}

Then you can build by:

$ docker bake

And in the CI:

– name: Build and push with docker bake
uses: docker/bake-action@v5
with:
files: ./docker-bake.hcl
push: true

If you’re not using Docker Bake yet, it’s worth looking into. It makes Docker build more delicious.

Caption: Docker Commandos doing a bake-off competition in Asgard

If you could containerize any non-technical object in real life, what would it be and why?

I would create snapshots of the world so that I can choose which version to live in. Sometimes I play Fallout: New Vegas to escape reality, which is ironic. But at least it has Big Iron in it.

Where can people find you online?

I have a website with all my links: aerabi.com

LinkedIn is my main social media platform; follow me there: /in/aerabi.

And when I miss the good old Twitter, I sometimes write on BlueSky: @aerabi.com.

Rapid Fire Questions

Cats or Dogs?

Homo Sapiens

Morning person or night owl?

Vampire

Favorite comfort food?

Fesenjān, but if you don’t know what that is, sushi

One word friends would use to describe you?

Crazy

A hobby you picked up recently?

Writing dark fantasy. Though honestly, lately I just call it “non-fiction.”

Quelle: https://blog.docker.com/feed/