Three types of AI agents, and how to pick one before you build

Hubzoid — Thu, 29 Oct 2026 16:24:10 +0000

Most internal AI projects don't fail on the tech. They fail because nobody decided what kind of agent they were building.

Some agent jobs start with a specific input. Some start with a question in plain language. Others start when a clock or an event fires. Those differences decide what a useful answer looks like, and what can go wrong.

So choose the shape of the work before you choose the model or the interface.

The three shapes

Shape	Example	What it needs most
Specific task	Check this invoice against its purchase order	Named inputs and an agreed result format
Question-answering	What is our current returns policy?	Relevant knowledge and a source for the answer
Background work	Prepare the report every weekday morning	A schedule, bounded runs and an owner

The failure mode is mixing them

Trouble starts when a job of one shape is built as another:

A Q&A bot sold as a tool. People expect a predictable result and get a conversation that answers a slightly different question each time.
A flexible tool frozen into automation. Something that needed a person to read and adjust the output now runs at 7am with nobody watching.

The shapes are patterns, not product categories. A chat can ask for an invoice check, and a scheduled job can use an agent to explain exceptions. What matters is that each job gets what its shape needs.

Specific tasks need a contract

An invoice check says what it expects: an invoice, a purchase order and the current matching rules. It says what it returns: matched lines, mismatches and any missing document.

Use code for exact comparisons and arithmetic.
If the model reads messy text, check its extraction before treating it as fact.
If the result feeds another process, validate the structure and give failures their own explicit outcome.

A paragraph that looks convincing is not a contract. A fixed output format doesn't make every model-generated value deterministic, either.

Questions need sources and room to clarify

People ask the same policy question in many forms. A useful Q&A agent finds the current policy, names its source and asks a follow-up when the answer depends on details it doesn't have. A returns question may depend on the purchase date or the account type, and guessing them changes the answer.

Test the refusal too. Ask for a number the agent's sources don't hold, and check that it says what's missing instead of estimating from unrelated data.

Background work needs a failure plan

When nobody is watching, a duplicate report or a silent failure can go unnoticed for days. Before you schedule anything, answer:

What starts the work, and which timezone applies?
Which account does the run act as, and what may it access?
Where does the result appear, and who reviews it?
What happens if an input fails or the process restarts?
Could repeating a step send a second message or change a record twice?

The last one bites hardest. If a run restarts halfway, any step with an external effect needs its own protection against running twice.

Before you build, write four lines

For the job you have in mind:

Input:    what the agent receives, and from whom
Output:   the exact result, and where it goes
Trigger:  a person asking, or a schedule or event
Failure:  what happens when an input is missing or a step fails

If you can't fill in the trigger, you don't know the shape yet.

See it in action

This short video shows the three shapes running on one shared set of team knowledge:

The longer version, including how each shape maps to chat, workflows and assistants over MCP in Hubzoid, is on our blog: Three types of AI agents, and when to use each.

Stop fixing your AI agents in chat

Hubzoid — Thu, 29 Oct 2026 16:23:55 +0000

The first mistake we made with internal agents: fixing them in chat.

You correct the agent, it does better, and then the next session forgets. A teammate's agent never knew about the correction in the first place. A week later someone fixes the same thing again, slightly differently.

The fix was boring. Every rule now lives in a file the agents read. A correction is a small edit, and every agent follows it on the next run.

Here's how that works in practice, and the three habits that kept it usable as it grew.

Why chat corrections don't stick

A correction in chat lives in one conversation. When that session ends, so does the rule. Assistants with memory keep it per person, so it still doesn't reach the colleague who asks the same question tomorrow.

Nobody can review it either. You can't see which rules the agent follows, who added them or whether two of them disagree.

Put the rule where the agent reads it

When the agent gets something wrong, ask one question: which file should have said this?

Then change that file. Say the agent reported gross sales when the team means net:

 ## Net sales
-Revenue for the period.
+Revenue for the period after returns and discounts.
+Use the finance export, not the CRM total. The CRM includes cancelled orders.

Commit it like any other change. The next run, in your session or a teammate's, uses the new rule.

You get three things chat never gave you:

One source. Every agent and every person reads the same definition.
History. git log knowledge/definitions.md shows who changed a rule and why.
Review. A rule that affects everyone can go through a pull request.

Habit 1: keep the top file a map

Our shared setup started with one big instructions file. It grew until the agent was loading pages of rules it didn't need for the job in front of it.

What fixed it was a short top file that is only a map of which file to read for which job:

# Team agent

Read only the files the task needs.

| Job | Read |
| --- | --- |
| Sales numbers | knowledge/definitions.md, knowledge/sources.md |
| Weekly stock review | skills/weekly-stock-review/SKILL.md |
| Anything sent outside the team | knowledge/approvals.md |

Agents now load two or three files instead of the whole repo, and people can find a rule without scrolling.

Habit 2: plain Markdown the agent searches itself

We keep the agents' knowledge as plain Markdown files and let the agent search them, instead of running them through an embedding index first.

There's no index to drift out of sync with the files, because there's no index. People can read and fix the same files the agent reads. And when the data gets larger, grep still works wonderfully well.

The Claude Code team has described a similar path: they started with a vector database and moved to the agent searching the files itself.

Habit 3: one folder per kind of thing

A layout that has held up for us:

team-hub/
├── AGENTS.md              # the map
├── knowledge/
│   ├── definitions.md     # what "net sales" means here
│   ├── sources.md         # which export is current
│   └── approvals.md       # what needs a person's sign-off
└── skills/
    └── weekly-stock-review/
        └── SKILL.md       # the steps for one recurring job

Definitions and sources go in knowledge/. Repeatable procedures go in skills/. Every correction has an obvious home, which is most of the point.

When it's more than your repo

Committing your setup to a repo works for people who work in that repo with the same coding assistant. The rules usually need to reach people who don't: someone in ops asking in chat, or a report that runs at 7am.

That's what we built Hubzoid for. A Hub is a folder like the one above. The same files serve a team web chat, scheduled workflows and assistants such as Claude Code and Codex through MCP, so one correction reaches all of them. It's open source (Apache-2.0) and self-hosted: github.com/hubzoid/hubzoid.

Whatever you use, the habit is the same: when the agent is wrong, fix the file, not the chat.

DEV Community: Hubzoid