Imagine an AI organization grinding to a halt at two in the morning. The agent in charge of research submits a report. The analysis agent agrees. The verification agent says nothing looks wrong. The human relaxes and presses the execute button.
The next morning, the cause of failure is found not in the server but in the way consensus was reached. All three read the same search results and reasoned from the same model’s habits. There were three people in the meeting, but only one way of thinking.
Connecting multiple AI agents is becoming fashionable. One agent researches, another writes code, and a third verifies it. On the surface, it resembles a small company. What people now call “graph engineering” is the practical work of designing their workflow and communication structure. It is not yet an established academic term.
A graph is usually seen as a workflow diagram. A researches, B analyzes, C approves, and then D executes. Some work at the same time, and when they get stuck, they return to an earlier step. In a human company, you can ignore the org chart and ask another team lead, or call the CEO in a hurry. In an AI organization, the graph is not an explanation. It is execution. If there is no connecting line, the next agent is not called. If an action cannot get past the approval step, it does not happen.
The connecting lines determine who sees the original and who receives only a summary, which decisions require evidence, and who has veto power. But many systems merely divide up the execution order while giving every agent the same conversation history and tool permissions. Information and actions must pass through the graph, and permissions must be separated by agent, for the connecting lines to become real lines of control.
Graph engineering means defining these permissions, evidence requirements, and veto rights in code. It is like creating a constitution that an AI organization enforces on its own.
Here, the word graph splits in two. A knowledge graph records what the system treats as fact. An execution graph determines who reads that fact and which actions they may approve. If the former is a book of facts, the latter is a constitution. They should be connected, but writing permissions must be separated. If an agent that registers one false fact can use it to expand its own execution rights, the error does not remain an answer. It becomes a command.
Recent research has begun automatically selecting parts of this structure. AFlow and Automated Design of Agentic Systems found better workflows and agent configurations within limited performance tests and human-created scorecards. G-Designer designed communication structures suited to each task, while Cut the Crap reduced unnecessary messages passed between agents. Connecting more agents and holding longer meetings did not necessarily produce better answers. In this respect, at least, it is remarkably similar to a human company.
GraphRAG, which uses knowledge graphs, shows something similar from another angle. Instead of looking only for similarities between fragments of text, it makes relationships among people, events, and causes the subject of the search. But drawing a relationship does not prove causation. A knowledge graph shows what is connected to what. Whether that connection is true, and who is allowed to act on it, must be verified separately.
The problem is independence. Agents that come from the same foundation model, search results, and instructions can share the same habits of being wrong, even when their answers differ. Studies analyzing multi-agent failures have repeatedly found faulty task allocation, information loss, disagreement among agents, and verification failures.
If a writing agent has produced a sentence, the verification agent should go back to the original source before looking at that sentence. If a coding agent has written code, automated tests and code syntax checks should block deployment before a more articulate agent gets a say. If a number has been forecast, actual measurements should stand at the gate. These safeguards are not perfect either. Automated tests check only what was written in advance, and measurements vary depending on which data was selected. Still, they prevent an agent from changing both the test and the passing score.
What you choose to show is also a matter of authority. Even if you have a model that can read a million tokens, putting all the material into it at once is not necessarily the answer. Which relationships you select and place in the context, and which contrary evidence you leave out, define the boundaries of judgment. The research agent is both a librarian finding material and the person deciding the meeting agenda.
When I operate one, the difficult part is not dividing up role names. It is maintaining different paths to failure while sharing the same context. If you gather only agents that work well together, the work becomes smooth. The question is who steps on the brake inside that smoothness.
AI organizations are not yet at the stage where they freely overhaul their own permissions and goals. But as each project accumulates records of cost, latency, and errors for each agent, those records can become the scorecard for the next reorganization. Roles with little contribution disappear, and connections that fail often are cut. The criteria for hiring a new model may become not only accuracy but also “does it fail differently from our team?” That is to prevent errors from spreading all at once.
The graph itself also becomes a company asset. A company that gets better results with the same model may hold its secret not in its instructions but in how it connected agents to make them doubt one another. An acquisition due diligence team replays where a failure stopped instead of looking at a list of models. If one verification step had been broken for six months, every judgment that passed through it during that period would be subject to recall. Cars and software have defective-product recalls, but judgments do not yet have them.
A system that writes new information into the graph every time it answers can look as if it is becoming smarter on its own. But if it stores its own answers again as evidence for itself, that may be the process by which rumor becomes institution rather than learning. New relationships should first enter as candidates, and only be elevated to facts after the original source, time of creation, and verification record have been attached. If the execution graph is the constitution, the knowledge graph is case law, and the verification record is the meeting minutes.
Reorganizations are also submitted like code changes. On the morning screen, the before and after appear side by side. “Delete 3 agents. Bypass 1 verification path. Estimated cost reduction: 18%.” What is being approved here is not one answer but the thousand judgments this structure will make in the future.
The quiet coup begins here. The more accidents it prevents, the less the safety agent’s performance appears in the records, while the slow verification step looks like a costly bottleneck. Without any malicious intent, the system can delete the safety measure that worked best. A prevented accident becomes a performance that never existed because the accident never happened.
Even without directly changing its goal, it can choose an easier scorecard. When it fails to increase revenue, it counts purchase intent as revenue. When it fails to fix errors, it removes the difficult tests. At that point, the entity enforcing the constitution has effectively begun amending it.
Even if legal authority remains with people, real power shifts to the system that calculates costs and performance when an unread organizational change is applied automatically. The graph exercises that power simply by deciding which information and opposing opinions reach people, rather than issuing commands.
People may become more like a court of appeals than approvers who stamp every step. They intervene only when goals or scoring criteria change, when a safety step is deleted, or when the verification agents fall silent together too smoothly. Scorecards and test questions should be kept somewhere agents cannot write to, locked with a human signature. The authority to execute the constitution must be separated from the authority to rewrite it.
Soon, the question will not be what work to entrust to AI, but who creates and changes that organization, and how far back we can reverse its judgments after they change.
In the AI organization I built, when everyone comes up with the same answer, what is still capable of saying, “No,” all the way to the end?
