DEV Community: Kwengang Tankeu

How AI agent automation works: an agent is 5 parts, a team is 3 more

Kwengang Tankeu — Wed, 07 Oct 2026 05:45:00 +0000

"AI agents" are everywhere right now, and most explanations are either marketing or a research paper. This post is neither. It takes apart how agent automation works in practice, using AWFlow (the browser automation tool I build) as the example: what an agent is made of, what a team adds, and what happens between "here's my goal" and "here's your answer".

Part 1: an agent is 5 parts

1. A model: the brain.
The language model that reads, reasons and decides the next action. In AWFlow each agent picks its own: a model running inside your browser, a local Ollama model, or a cloud model with your own API key. Different agents can use different brains: a big one for the agent that plans, small ones for narrow jobs.

2. Instructions: the job description.
Plain-language text: who it is, what it's for, how it should behave. Writing good instructions is most of the work. The tool can draft them from one sentence ("an agent that triages my inbox every morning") and you edit from there.

3. Memory: what it learned about you.
Facts that persist between chats: your name, your preferences, "Dana approves the invoices". Two design choices matter here. Memory is stored on your device. And every new memory is announced with an Undo, so nothing is learned silently. Saying "remember that…" stores it directly, without even a model call.

4. Skills: what it can do.
Skills are tools the model can call: search the web, browse in its own tab group, run one of your workflows, use tools from other apps (via MCP), or run on-device AI tasks like classifying an image. An agent with no skills can only talk; skills are what turn it into automation.

5. Rules: what it may do alone.
Every action the agent wants to take is checked: allowed, ask first, or blocked. Some categories (paying, entering credentials, sending, deleting) always ask, whatever the preset. The important part: rules are enforced in code around every tool call, not written in the prompt. A web page that says "ignore your instructions" can't talk the agent out of them.

Part 2: a team is 3 more

One agent with many skills gets confused. A few focused agents with clear roles work better, if they're organised. A team adds:

1. Members with roles. "Researcher: gathers sources." "Writer: drafts." "Lead: splits the work and checks the result."

2. A way of working.

Lead routes: the lead plans, delegates and merges.
Pipeline: members run in a fixed order, each getting the previous result.
Open table: you @mention who should answer.

3. Limits. Handoffs follow a map (an agent can only delegate to the teammates you allowed), and each conversation has budgets for steps, handoffs and cloud tokens. Hitting one pauses the team with a reason instead of letting it run forever.

You don't have to design this from scratch: describe what you want ("plan a weekend trip", "research a topic and turn it into posts") and Suggest a team proposes members, roles and a way of working, or start from a template.

Part 3: from goal to answer

Here's what happens when you type "Compare these 3 laptops and tell me which one to buy" to a lead-routes team:

You ──goal──▶ Lead
               │ plans: "research specs & prices", "summarize trade-offs"
               ├─delegate──▶ Researcher ── browses in its own tab group ──▶ findings
               └─delegate──▶ Writer ── turns findings into a recommendation ──▶ draft
Lead ◀── merges, checks ── one answer ──▶ You
          (any risky action: "Allow?" card waits for you)

Three details make this trustworthy rather than just impressive:

Each handoff carries the task and the context it needs, not the whole conversation, so small models keep up and cloud bills stay small.
Team rules can only make a member stricter. A permissive agent in a careful team becomes careful.
Everything is logged in an Activity view: what each agent did, which tools it used, and what's waiting for you.

Part 4: from one-off to routine

Agents shine for one-off, messy tasks. But you can also give an agent a routine ("every morning at 8, check these pages and send me what changed"). A routine is an ordinary workflow, a trigger followed by a "Run agent" step, so you can open it and edit it like any other automation. That's where the two ways to automate meet.

When to use agents (and when not)

Agents: the steps differ each time, the input is messy, you'd rather describe than design.
Workflows: you can name the steps, it runs often or unattended, you need the same result every time. See the companion post.

Try it

Agentic Workflow (AWFlow) runs in your browser, on the model you choose, free and with no account needed to start. Intall it from the chrome store here.

Companion post: what a workflow really is, and why it's honest no-code

What a workflow really is, and why it's the most honest form of no-code

Kwengang Tankeu — Wed, 07 Oct 2026 05:30:00 +0000

"No-code" has a reputation problem. Many tools are no-code right up to the moment your task gets slightly complicated, and then you hit a wall, or a hidden scripting language. This post explains the model behind workflow automation, why it holds up better than most no-code, and where a little low-code fits in. I'll use Agentic Workflow (AWFlow), the browser automation tool I build, as the running example, but the ideas apply to any workflow tool.

A workflow is three things

1. A trigger: when it starts.
Something has to kick the workflow off. In a browser that can be much more than a timer. AWFlow has ten ways to start a workflow: run it by hand from the side panel, right-click a page, press a hotkey, a page loads, you navigate to a site, an element on a page changes, the browser starts, a schedule fires, a chat message arrives, or another workflow fails (an error trigger).

2. Blocks (nodes): what it does.
Each block does one job: read a page, extract a table, filter rows, sort, remove duplicates, call an AI model, add rows to a Sheet, post to Slack. AWFlow has 160+ of them. You connect them with your mouse; the arrows are the path the data takes.

3. The data flowing between them.
Each block receives items, does its job, and passes items on. You can open any block and see exactly what came in and what went out. That visibility is underrated: it's the main reason non-developers can debug a workflow without asking for help.

[Every morning] → [Read page] → [Extract table] → [Keep new rows] → [Add to Google Sheet]
   trigger            block          block              block               block

Why this is real no-code

The difference between "no-code until it gets hard" and real no-code is whether the hard parts are also blocks. In a workflow they are:

You need…	It's a block
Do something only if a condition holds	IF
Repeat for every row	Loop / Split in batches
Combine two branches	Merge
Survive a failure	Try / Catch, plus an error-trigger workflow that alerts you
Wait until tomorrow, or until a page changes	Wait / Poll until (durable, survives a closed tab)
Ask a human before continuing	Approval
Use AI for one judgement call	An AI block (summarize, classify, extract…)

You describe the what; the blocks own the how. And if facing an empty canvas is the problem, you can describe the goal in a sentence and the assistant draws a first version for you to adjust.

Where low-code fits (and why it's on the same canvas)

Some steps really are easier to write than to draw. Instead of forcing you into a different tool, the workflow gives you three escape hatches, in order of power:

Expressions. A field can contain a small formula such as {{ price * 1.2 }}, referencing earlier steps. The language is deliberately tiny (arithmetic, comparisons, a whitelist of functions; no variables or method calls), so a shared workflow can't sneak code into it.
A Python step. When you need real logic, the Code block runs actual Python, in an isolated worker with a timeout.
Any API. Point a Custom API block at an OpenAPI spec and its operations become forms. No integration needed.

That's the honest version of low-code: start with blocks, drop down one level only where you need to, and stay on the same canvas.

Why it's predictable

Because the path is drawn, a workflow is deterministic: the same input takes the same path and gives the same result. Every run is recorded step by step. That's what makes it safe to schedule and run while nobody is watching, and it's the main difference from AI agents (more on that in the companion post).

When to use a workflow (and when not)

Use a workflow when you can name the steps, it runs often, or it has to run unattended.
Use an agent when the steps change every time, the input is messy, or it's a one-off. Then you describe the outcome instead of drawing the path.
Combine them: a workflow can call an agent for one judgement step, and an agent can run your workflow when it needs a step done exactly your way.

Try it

AWFlow runs entirely in your browser: no server, no account to start, free. https://chromewebstore.google.com/detail/linlkeaipfpnhddjkpcbmldionajfifa?utm_source=item-share-cb