What's actually happening when an Agentic AI system does things for you?

You’ve probably heard people throwing around terms like „AI agents”, „orchestrators”, „containers” and „webhooks” — on the street, at the office, over coffee, in LinkedIn ads. It sounds important. It sounds complicated. It sounds like something you should already understand.

Let me let you in on a secret: you shouldn’t have to. Nobody was born knowing these words. And most of the people who throw them around don’t really explain them because, honestly, they’re not quite sure themselves.

This article will explain, without talking down to you, what these „digital creatures” actually are and how they live together to get things done for you. We won’t make you a programmer. We’ll make you someone who understands what they see around them.

And we’re going to use, throughout, the hotel analogy — because it works surprisingly well. By the end of this article, you’ll have a clear picture in your head: a big hotel, with staff in different uniforms, each with their own role, everything orchestrated like a well-rehearsed ballet.

---

1. The big difference: AI that replies vs. AI that acts

We start with a fundamental distinction.

There are two types of AI you can encounter in the world:

Type 1 — AI that replies. You ask it something, it answers. That’s it. ChatGPT, in its classic form, is like this. You ask „how do I cook pasta”, it gives you the recipe. The conversation ends there. If you close the browser, it does nothing more — it has nowhere to go, nothing to do.

Type 2 — AI that acts. This one doesn’t just reply. It takes action in the world. It sends emails. Schedules meetings. Buys tickets. Monitors events. Notifies you when something happens. And — this is the important part — it keeps existing even when you’re not there.

The second type is called an agentic system. And behind it, there isn’t just „one AI”. There’s a whole team. With clear roles. With a shared home. With communication rules.

Just like in a hotel.

Our Demeter platform is exactly this — a team of autonomous agents that orchestrate real business workflows, with full audit for every action.

---

2. The four main actors

Picture a large hotel. Four-five stars. Plenty of staff, each in their uniform. Let’s meet them.

🧹 The housekeeper — the agent

In two sentences: The housekeeper is the one who does the actual work. Cleans, restocks, organizes, reports. She’s there all day, paid for what she does with her hands.

In AI systems, she’s called an agent. It’s a program that lives non-stop and that does a real thing in the world. It doesn’t just reply — it acts.

Essential traits:

• Has one main job and knows it very well
• Stays available 24/7 — doesn’t start from scratch with every request
• Has memory about what she’s done and what’s left to do
• Can make her own decisions within given limits

Why a housekeeper and not a consultant? Because she doesn’t come to tell you „I think you should do X”. She comes, does X, lets you know it’s done.

A real system usually has multiple agents, each with a specialty: one handles email, another the calendar, another payments, another monitoring. Not one agent who does everything — that would become chaotic. Imagine a hotel with one housekeeper who also does reception, kitchen, and plumbing. Doesn’t work.

🔧 The specialist — the sub-agent

In two sentences: The specialist is the person who comes only for one specific thing. Polishes the mirrors. Or checks the electrical system. Or brings in an industrial vacuum when it’s needed.

In AI systems, he’s called a sub-agent. He’s a specialized piece that an agent uses when needed. He doesn’t live on his own, doesn’t have his own room — he appears when called and leaves when he’s done.

Why does he exist? Because it would be absurd for every housekeeper to know how to do everything perfectly. It’s more efficient to say:

• „You, housekeeper, decide what needs doing in the room.”
• „You, mirror specialist, come polish them.”
• „You, carpet specialist, come give them a proper clean.”

Each with their own job. You replace one without breaking the rest.

Real-world examples of sub-agents: „the one who classifies”, „the one who summarizes”, „the one who validates an email address”, „the one who translates between languages”. Each is very narrow, but very good at what it does.

🎩 The concierge — the orchestrator

In two sentences: The concierge doesn’t do actual work. Doesn’t clean. Doesn’t cook. Doesn’t repair. But without him, nobody knows what to do.

In AI systems, he’s called an orchestrator. The name comes from „orchestra” — and indeed he’s like a conductor: doesn’t play any instrument, but without him the musicians can’t come in on time.

What he does, concretely:

• Receives a request (from a client, from the internet, from anywhere)
• Decides who should handle it
• Sends it to the right person
• Records what happened

Watch out for a common mistake: many people think „the orchestrator is the smart one, the agents just follow orders”. It’s exactly the opposite. The orchestrator is deliberately „dumb” — it only knows how to route, to direct traffic. The agents are the ones who actually decide what to do with each request.

Why this way? Because if you put the real logic („how do we solve X”) into the orchestrator, it becomes a maintenance nightmare. With separate agents, you change how one agent works without touching anything else. The concierge doesn’t need to know how to wash a pillowcase — just who to send it to.

👮 The floor manager — the supervisor

In two sentences: The floor manager doesn’t do useful work for the guest. He just walks, periodically, through all the rooms and checks that everything is fine.

In AI systems, he’s called a supervisor. His job is one single question, asked over and over: „Are you still alive?”

How does he check? He sends a short query to each agent and looks at the response:

• 🟢 Quick, clear reply → all good
• 🟡 Slow or delayed reply → caution
• 🔴 No reply at all → alarm, wake someone up

These checks are called healthchecks. And if an agent is dead, the system restarts it automatically. More on that in the next section.

Summary table

Role	Does real work?	Makes decisions?	Lives 24/7?
Housekeeper (Agent)	✅ Yes, that’s their main job	✅ Yes, in their domain	✅ Yes
Specialist (Sub-agent)	✅ Only one very narrow thing	⚠️ Only about their specialty	❌ Shows up on demand
Concierge (Orchestrator)	❌ No, just routes	❌ Only „who gets what”	✅ Yes
Floor Manager (Supervisor)	❌ No	❌ Only checks health	⏰ Walks by periodically

---

3. Where do they live? — container, Docker, Swarm

Okay, we’ve established who they are. But where do they stay, these agents? On which computer? How do they not step on each other?

This is where those buzzword-sounding words come in: container, Docker, Swarm.

📦 Container — the agent’s personal room

Imagine an apartment building with many flats. Each flat is fully furnished, has its own facilities, is isolated from the neighbors. What happens in your flat doesn’t affect your neighbor’s flat. You have your own key. Your own things.

A container is exactly that, but for programs. It’s a „digital apartment” in which a program (an agent, for example) lives along with everything it needs to function — libraries, configuration, files, everything.

Why is this brilliant? Because it solves the „works on my computer” nightmare. If your program is in a container, it’ll run identically on your laptop, on a cloud server, on any machine. The container carries its house with it.

🐳 Docker — the company that builds the rooms

Docker is the name of the technology that creates and manages containers. It’s like the construction company that built the apartments, but also like the building manager who keeps them running: starts them, stops them, moves them.

In practice, when someone says „run this in Docker”, they mean: take the program, package it in a container, and start it.

🐝 Docker Swarm — the hotel with automatic management

Now imagine not just one building, but an entire residential complex with many buildings. And smart management that:

• Notices when an apartment has problems and moves the tenant to another one
• Ensures that if one building falls, tenants aren’t left on the street
• Distributes new tenants to the buildings with the lowest occupancy
• Checks every 30 seconds whether each apartment has power

Docker Swarm is exactly that: a system that coordinates many containers across multiple servers, ready to restart them if they die, to move them if a server goes down.

This is what makes the difference between „I ran a program on a computer” and „I have a system that runs non-stop, without anyone needing to babysit it”.

For those who’ve heard of Kubernetes: Kubernetes does the same thing as Swarm, but is more powerful and more complicated. They’re in the same family of solutions, just at different scales. Just as Marriott is bigger than a small local chain — same business, different scale.

---

4. How do they „hear” and „talk” to each other?

Alright, the agents are in their rooms. But how do they hear when someone calls them? How do they communicate with each other?

This is where the words that confuse people the most come in, because they sound similar: webhook, hook, pub/sub, API. Let’s clear them up with three simple metaphors — all from the hotel.

🔔 The doorbell — webhook

Imagine you’re at reception. Someone comes from outside. Rings the doorbell. You hear it immediately and respond.

A webhook is exactly that, but for programs. It’s an address on the internet (a URL) where someone else can „ring” by sending a small notification. Your program hears the bell and reacts.

Concrete example: when you pay for something online with your card, the bank sends a webhook to the shop you bought from: „hey, the payment went through!”. The shop hears it, marks the order as paid, sends you confirmation. You see none of this — but without webhooks, the shop wouldn’t know when to ship your product.

Typical confusion: „hook” and „webhook” sound alike, but they’re not quite the same thing. Webhook = bell from outside. Hook = a peg where you can hang something on the inside. We’ll talk about hooks below, in the skills section.

📻 The internal radio — pub/sub

Now imagine the hotel’s internal PA system. The concierge presses a button and announces over the speakers:

„All housekeepers on floor 3, please come to room 305.”

The speakers broadcast the announcement across the entire hotel. But only the housekeepers on floor 3 react. The others hear it, but it’s not their business. The concierge (the one announcing) doesn’t need to know where each housekeeper is — he just publishes on the „floor 3 channel” and all interested parties hear.

This is the pub/sub model (publish/subscribe):

• Someone publishes a message on a named channel
• Those who’ve subscribed to that channel receive the message
• The rest aren’t disturbed

Popular technologies: Redis, RabbitMQ, Kafka. Their names come up often in technical conversations — they’re different brands of „internal radio”.

📞 The direct phone — API

The last variant: you want to ask one specific person something specific. You call them directly, get a reply, hang up.

An API (Application Programming Interface) works exactly like this: the way two programs talk directly to each other. Clear question, clear answer, one-to-one conversation.

Examples: when your agent sends an email, it uses the Gmail API. When it books a flight, it uses the airline’s API. When it posts to Twitter/X, it uses their API. APIs are the hands through which the agent touches the outside world.

⚡ And one more bit of magic: how an agent does many things „at once”

There’s a big confusion here. Let’s clear it up with a story.

Picture a super-efficient housekeeper, Saturday morning. She has to: do the laundry, make soup for staff, bake a cake for guests, and answer the internal phone when it rings. How does she manage?

The bad approach: put the laundry in, stand next to the washing machine for an hour doing nothing, only then start the soup. Totally inefficient.

The smart approach:

1. Put the laundry in and leave — the machine runs on its own
2. Start the soup, chop the vegetables
3. Hear the machine’s beep — go back and start the dryer
4. Continue with the soup
5. The phone rings — answer it
6. Meanwhile put the cake in the oven
7. Check all three while still on the phone

This is the housekeeper with an event loop. She’s just one person, but because her job mostly involves waiting for things (the machine, the oven, the phone), she uses the waiting time to do something else.

That’s what allows an agent to listen to requests through webhooks, respond on the internal radio, run its scheduled chores — all seemingly at the same time — without needing multiple parallel „brains”.

---

5. What do the agents „know” how to do? — skills, plugins, LLM

Alright, the agents listen, communicate, are alive. But how do they know what to do exactly?

🎯 Skill — the recipe from the kitchen

A skill is a package of instructions that teaches an agent how to do something specific.

Analogy: a skill is like a recipe card pinned on the kitchen wall of a hotel. „How to make the perfect hollandaise sauce” — one card. „How to prepare bread dough” — another card. The cook (the agent) is the same person. The recipe teaches them what to do in a particular situation.

The cook reads the recipe before cooking, follows the steps, delivers the result. Tomorrow, if a new recipe comes in, you pin it on the wall and that’s it — the cook has learned a new dish.

🔌 Plugin — the industrial vacuum

A plugin (from „plug in”) is a real tool added that extends what an agent can do.

Analogy: if the housekeeper has basic tools (cloth, bucket, broom), plugins are the industrial vacuum you bring out of the storage room only for special occasions, or the carpet washing machine, or the dust blower for the paintings. The housekeeper wasn’t using them yesterday. She is today. She’s learned how to use them. Now she does more than before.

Plugin vs Skill — the difference:

• Skill = instructions („how something is done”)
• Plugin = a real tool added („what it’s done with”)

In practice, the line blurs — many systems use the words almost interchangeably.

🧠 LLM — the „thinking brain”

Here we get to the heart of the matter. What truly makes an „AI agent” intelligent? Why is it not just an ordinary script?

The answer: LLM — Large Language Model. ChatGPT, Claude, Gemini, Llama — these are LLMs. They’re the „brains” that agents use to understand natural language and decide what to do.

Watch out for the big confusion: an agent is not an LLM. An agent uses an LLM, but it’s much more than that. The LLM is only the thinking part. The rest (how it acts, where it stores data, how it communicates, how it hears commands) is all „ordinary” code around it.

It’s like the difference between a driver and a car with a driver. The LLM is the driver. The agent is the car with a driver plus all the systems that make that car exist in the world: fuel, insurance, GPS, parking, maintenance. Without a driver, the car doesn’t go anywhere. But just a driver without a car doesn’t take you anywhere either.

---

6. Their rhythm of life — cron and fixed moments

An agent acts in two rhythms:

1. Reactive — when someone asks for something (through the bell/webhook, on the radio/pub-sub, or directly on the phone/API)
2. Proactive — at preset times, without being called

For the second rhythm, the word cron comes in.

⏰ Cron — the programmed clock

Cron is a system that starts programs at exact moments. „Every day at 03:00”, „Every Monday at 9 AM”, „Every 5 minutes”.

It’s old (it’s been on Linux systems for decades), simple, and extremely reliable. Every server has one. It’s like the housekeeper’s daily schedule on the bulletin board: „09:00 — floor 1. 10:30 — break. 11:00 — floor 2.”

Examples of use in agentic systems:

• Every 5 minutes: the Iris supervisor checks the agents’ health
• Every night at 3 AM: the backup agent saves the data
• Every Monday morning: the reporting agent sends the weekly report

There’s also a more modern variant: instead of an external cron, the agent has an internal alarm that wakes it up on its own, without outside help. Both variants work. In modern systems they’re often used together.

---

7. MVP — Where do you start when you build something like this?

This is the section you need to read if you ever feel tempted to build an agentic system.

MVP = Minimum Viable Product. In plain English: „the smallest version that actually works”.

The 200-room hotel that never opens

Imagine someone who wants to open a hotel. They’re ambitious. They want a spa, a Michelin-starred restaurant, a conference hall, 200 rooms, valet parking, bedside room service, golf, a canine therapist, an in-house sommelier.

How long will it take them to open? Most likely — never. They’ll stay forever in the planning stage. Because every extra piece doubles the complexity.

Now imagine someone else who says: „I’ll open a 10-room B&B. Simple reception. One housekeeper. Continental breakfast, no kitchen. That’s it. Let’s see how it goes.”

The second person opens in 3 months. Gets the first customers. Learns. Grows. After a year, they already have experience and know exactly what to add — because the real guests have told them. They can add the restaurant when they have proven demand. The spa when they have money and space.

Same with agentic systems

The temptation, when you see the words „orchestrator, sub-agent, supervisor, Swarm, healthcheck, pub/sub”, is to believe that all of them are needed from the start. They’re not.

An MVP agentic system can have:

• ✅ A single agent that does one useful thing
• ✅ A simple Docker container on one server
• ✅ A cron that wakes it up periodically
• ❌ No orchestrator (no need when you have one agent)
• ❌ No sub-agents (the agent does everything initially)
• ❌ No supervisor (you check the logs manually in the first month)
• ❌ No Swarm (one server is enough)
• ❌ No pub/sub (the agent talks directly to what it needs)

And that’s enough. If it works, if people use it, if it provides real value — then you add the pieces when you actually need them:

• A second agent appears? → Now you need a way to coordinate them. The orchestrator arrives.
• The agent gets too heavy? → You split parts into sub-agents.
• It crashes often? → Now you need Swarm and healthchecks.
• Multiple agents send messages to multiple agents? → Now you need pub/sub.

Golden rule: don’t build for 1000 users when you have 2. Don’t build for 100 agents when you have 1. Add complexity only when the pain of NOT having it becomes greater than the pain of having it.

Many projects die because the team built „the right architecture” from scratch — and burned out before delivering anything real. Start simple. Grow when reality tells you to.

---

8. A day at the hotel — the journey of a request

Now that we have all the pieces, let’s put them together. What does an ordinary request look like, from coming into the system to coming out as a result?

Scene 1: The guest asks for something

A client uses an app. Types something or presses a button. „I want to book a meeting for tomorrow”. „Log this expense for me”. „Send me a report with this week’s sales”.

Scene 2: The doorbell rings at reception (webhook)

The request instantly arrives at the system’s entry URL. The concierge (the orchestrator) hears it.

Scene 3: The concierge decides who handles it (orchestrator)

The concierge takes a quick look at the request: „It’s a booking request → I’ll send it to Housekeeper B. It’s a report request → I’ll send it to Housekeeper C.”

Then makes the announcement: over the internal radio (the pub/sub system), on the „bookings” channel.

Scene 4: The housekeeper hears and gets started (agent)

Housekeeper B is subscribed to the „bookings” channel. Receives the message. Understands what needs to be done. Starts working.

Scene 5: Calls the specialist if needed (sub-agent)

„Before I make the booking, I want to verify the data is valid.” Calls the validation sub-agent. The sub-agent does one thing: checks the data. Replies: „OK” / „Not OK”. And leaves.

Scene 6: The housekeeper finishes and logs it (audit + storage)

The action is performed in the real world — the booking is made, the report is generated, the expense is saved. Everything is logged in the system’s archive, so we know what happened. If you ever need to check „who did what and when”, the archive tells you.

Scene 7: The guest receives the response

Push notification on the phone, an email, a message — whatever channel was requested. The client sees it’s done.

And meanwhile…

In the background, the floor manager (the supervisor) keeps walking by every 5 minutes to each one. Does the concierge reply? 🟢 Does Housekeeper B reply? 🟢 Does the validation specialist reply? 🟢 All good.

If any of them failed to reply, Docker Swarm would automatically restart them. Within seconds, the system is whole again.

The total process, from the moment the guest asks for something to the moment they receive the response: a few seconds.

---

9. Why is it built this way? — frequently asked questions

„Why not one big program that does everything?”

Because:

• If it crashes, everything crashes
• If you want to update it, you have to stop it completely
• If it grows, you can’t parallelize
• If someone breaks a part, they break the rest

With separate agents: one falls, the others keep going. You change one agent without touching the rest. You scale up the pieces that need it, without bloating everything.

„Isn’t the orchestrator the most important? It runs everything.”

Quite the opposite. The orchestrator is the dumbest of the actors — it only knows how to route. The agents are the smart ones. If the orchestrator becomes smart, the system becomes unmaintainable. The hotel’s concierge doesn’t need to know how to wash a pillowcase — just who to send it to.

„Do AI agents fully replace humans?”

Almost never. Well-built agentic systems have points of human approval at critical moments. The agents do the heavy lifting, the human makes the important decisions. Just as a hotel has lots of staff — but there’s still someone who decides to buy new furniture.

„If I talk to an agent, am I talking to the LLM?”

Partly. You’re talking to the agent, which uses the LLM to understand you and reply. But everything to do with „doing something in the world” is regular code around the LLM. The housekeeper may be the one who talks to you — but it’s not her mind that cleans the room. Her hands do.

„How much does it cost to run such a system?”

Highly variable. A simple MVP on a modest server can cost $20-50/month. Large systems with many agents and heavy usage can reach thousands of dollars per month (especially the LLM cost, if called frequently). Cost grows with volume, not just with complexity.

„Where do I start if I want to build something like this?”

Start simple. One agent. One clear job. A cron that wakes it up. See if it works. See if real people use it. Then you add pieces, one at a time. See the MVP section above — that’s the most important advice in this article.

If you’d rather skip the „build from scratch” part, platforms like Demeter give you the full stack out of the box (agents, orchestrator, supervisor, audit) — so you focus on what the agent does, not on the plumbing.

---

10. Quick glossary — for re-checking

Term	What it is	Hotel analogy
Agent	Program that lives 24/7 and does real work	Housekeeper with a fixed post
Sub-agent	Specialized function used by an agent	Specialist called on demand
Orchestrator	Routes requests to the right agent	Concierge
Supervisor	Checks the system’s health periodically	Floor manager
Container	Isolated package in which a program runs	Furnished hotel room
Docker	The technology that creates containers	The company that builds the rooms
Docker Swarm	Many servers coordinating containers	The hotel with automatic management
Kubernetes	More powerful variant of Swarm	The big hotel chain
Healthcheck	Automatic verification that a program responds	„Are you still alive?”
Webhook	Public URL where external systems „ring”	Doorbell
Hook	Internal point in code where you can add something	Peg on a wall
Pub/Sub	Message system on thematic channels	Internal radio
Redis / RabbitMQ / Kafka	Popular technologies for pub/sub	Brands of internal radio
API	Interface through which two programs talk	Direct phone
Event loop	Loop that processes events one after another	The super-efficient housekeeper
Cron	Scheduler that starts things at fixed times	The schedule on the board
Skill	Package of instructions learned by an agent	Recipe from the kitchen
Plugin	Real tool added that extends the agent	Industrial vacuum
LLM	AI model that understands and produces language	Thinking brain
MVP	The smallest version that actually works	10-room B&B
Audit	Recording of all the system’s actions	Reception’s log book

---

11. Conclusion: AI isn’t magic, it’s a well-organized team

If you’ve read this far, you already understand more than 95% of the people who use these words every day. Let’s summarize the big picture.

An AI agentic system is a team. Not a single „brain” — a team of programs that collaborate, each with their role:

• The housekeepers (the agents) do the real work
• The specialists (the sub-agents) help with very specific things
• The concierge (the orchestrator) directs traffic without doing the work himself
• The manager (the supervisor) checks every 5 minutes that everyone is alive

They all live in isolated rooms (containers), in a coordinated hotel (Docker Swarm) that restarts them if they fall.

They talk to each other through doorbells (webhooks for outside requests), internal radio (pub/sub for channel announcements), and direct phones (APIs for one-to-one conversations).

They’re programmed to act both reactively (when something is asked of them) and proactively (at fixed times, through cron).

Their „intelligence” comes mostly from LLMs (the thinking brains), but everything else — the action in the real world — is careful engineering around them.

And most importantly: you don’t need to build everything at once. You start with a 10-room B&B. You verify it works. You grow when reality tells you to. That’s what MVP means. That’s the difference between a project that ships and one that dies on the drawing board.

---

Now, when you hear someone say „we have an agentic system with an orchestrator and sub-agents communicating through pub/sub in containers coordinated by Swarm”, you’ll be able to smile and say to yourself: „I know exactly what they’re talking about. It’s a hotel.”

And that — understanding what you see, without being intimidated by jargon — is half the job.

---

References & further reading

• Anthropic — Building effective agents (2024) — canonical patterns for building agents.
• Docker — What is a container — canonical container definition.
• Docker Swarm overview — native Docker orchestration for distributed services.
• Webhooks vs APIs (Stripe Engineering) — practical webhook vs API distinction.
• Cron (Linux man page) — the classic scheduler still running the world.

---

This article is part of the „AI demystified” series published on caitech.eu. Upcoming articles will cover prompt engineering, RAG (how we give agents access to external knowledge), and observability (how we see what’s happening inside the system). Stay close.