Most people meet AI agents today through large language models. It is easy to assume the whole idea is new. It is not. Researchers were building and arguing about software agents for decades before chat models arrived: programs that hold goals, make plans, talk to each other and divide work. That older field, usually called multi-agent systems, solved several problems that new agent builders keep running into again. Knowing a little of it saves time and money.
Agents were always about goals, not just answers
One of the best known classical ideas is the BDI model: beliefs, desires and intentions. Beliefs are what the agent thinks is true about the world. Desires are the outcomes it would like. Intentions are the goals it has actually committed to and is working on right now.
The useful part is the split between desires and intentions. An agent can want many things, but it should commit to a small number and stick with them until they are done, impossible or no longer relevant. Without that commitment, an agent keeps changing its mind every time new information arrives and never finishes anything.
Modern language model agents show exactly this failure. Given a long task, they can drift, restart or chase a side issue. A practical lesson: make the agent write down its current goal and plan in a fixed place, and check new information against that plan before switching. You are giving it intentions in the classical sense.
Talking needs a shared vocabulary
Classical researchers spent a lot of effort on agent communication languages. The idea came from speech act theory: a message is not just text, it is an act. “Inform” tells someone a fact. “Request” asks them to do something. “Propose” offers a deal. “Refuse” declines. Each act has an expected response.
Today, many multi-agent setups simply pass free text between models. That works in a demo and breaks in production, because nobody can tell whether a message was a question, an instruction or a status report. If you build a system where one agent hands work to another, borrow the old discipline:
- Give every message a type, such as request, report, question or refusal.
- Include who sent it, what it refers to and what reply is expected.
- Log every message, so a person can replay the conversation later.
This is not bureaucracy. It is the difference between a system you can debug and one you can only restart.
Dividing work: the contract net and the blackboard
Two classical patterns for sharing work are still worth knowing by name.
The contract net protocol works like a small tender. A manager agent announces a task. Agents that can do it send bids describing what they offer. The manager picks one and awards the contract, and the winner reports back when done. It is simple, and it makes the decision of who does what explicit and recorded.
The blackboard system takes a different approach. There is a shared workspace, the blackboard, where the current state of a problem is written. Specialist components watch the board and add to it when they have something useful. A controller decides whose turn it is. It suits problems where nobody knows in advance which specialist will be needed next.
For a business, the choice between these maps to a familiar question. Is the work a series of clear jobs that can be handed out, like processing a batch of loan applications? That looks like a contract net. Is it a messy problem that several experts chip away at, like investigating a customer complaint that touches billing, delivery and stock? That looks more like a blackboard.
What the old field got wrong, or could not do
Classical agents were brittle. Their knowledge had to be written by hand as rules, and they failed badly on anything outside those rules. They could not read an untidy email, understand a WhatsApp voice note or cope with a customer who writes in a mix of Sinhala and English. Language models fixed much of that. They bring flexibility the older systems never had.
The trade is that modern agents are less predictable. A classical rule-based agent did the same thing every time. A language model agent may not. So the best current designs combine both: the flexible model does the reading and drafting, while old-fashioned structure (typed messages, explicit goals, clear task assignment, fixed approval steps) holds the system together.
There is also a plain limit. Much classical research assumed agents were self-interested and would compete, bargain or even deceive. Inside one company, your agents are not rivals. Some of the heavier theory, built for competing agents, is more than a small business needs.
A practical reading list, without the reading
You do not need to study the field to benefit from it. When someone proposes a multi-agent system for your business, ask four questions the classical researchers would have asked:
- What is each agent committed to right now, and where is that written?
- What kinds of message can agents send each other, and are they logged?
- How is work assigned: by announcement and award, or through a shared workspace?
- What happens when two agents disagree or both claim the same task?
If the answers are vague, the system will be hard to trust. If they are clear, you are looking at a design that has learned from decades of other people’s mistakes. More notes on this kind of groundwork are collected in our research section.