Those are not coding problems. They are the same problems that produced org charts, decision logs, handover notes and systems of record. Anyone who has run an operations team will recognise them immediately.
Three problems that look like software and behave like management
Context: who needs to know what
Every call to a model is a decision about information supply. Give an agent too little and it fills the gap with something plausible. Give it everything and the one instruction that mattered gets buried in the middle of a hundred thousand tokens.
Anthropic's engineering team describes the context window as a finite budget that has to be curated rather than filled, and treats the selection of what goes into it as its own discipline. In a company you would call the same activity briefing someone properly: the smallest set of facts that allows a decision, with the source named.
The difference between the two versions is easy to see in ERP work. Ask an agent to configure an invoicing rule and hand it a four hundred page functional specification, and it will produce something defensible and probably wrong. Hand it the three agreed acceptance tests plus the actual field definitions from the module it has to extend, and you get something a human can check in ten minutes.
Memory: what the institution keeps
Organisations forget constantly, and they forget in a specific pattern. The decision made in a call gets remembered by the four people on the call. The reasoning behind it disappears within a quarter. The person who understood why the warehouse uses two-step delivery leaves, and the knowledge leaves with them.
Agent systems fail the same way, only faster. A constraint discovered in one run is gone by the next unless somebody wrote it down in a place the next run reads.
This is why the useful unit of memory is not a transcript. It is a rule. When a developer says "never use a server action for that, it breaks on upgrade", the value of that sentence is realised only when it becomes a constraint that every subsequent generation has to respect. Said once, kept permanently. That is a filing decision, not a machine learning one.
State: one version of what is true right now
This is where multi-agent systems fail most often, and where the resemblance to a badly run company becomes uncomfortable.
Two agents each hold a copy of the plan. One updates its copy. The other keeps working from the version it started with. Neither is wrong from where it sits, and the output is two pieces of work that cannot both be merged. Walden Yan of Cognition made a version of this argument in "Don't Build Multi-Agents", pointing out that parallel subagents without genuinely shared context produce conflicting work rather than more work. Anthropic's own account of its multi-agent research system is candid about how much of the engineering effort goes into coordination rather than capability.
Enterprises solved this problem a long time ago, and the solution was boring: nominate a system of record, and make everything else defer to it.
What a failing agent system actually looks like
Watch one closely and it reads less like a stack trace than like a badly run company:
Decisions get forgotten, so the same question is researched three times with three different answers. Two agents duplicate work because neither knew the other had started. Nobody owns the source of truth, so the most recent write wins by accident rather than by design. And when the work is genuinely ambiguous, the system does not escalate. It commits.
The fixes are equally familiar. Clear handoffs. Written records at every stage. One accountable owner for each piece of state. Acceptance criteria agreed before work starts rather than argued about afterwards.
Read more in our blog
ERP implementation when the company has no standard processes
ERP is this problem, written down
There is a reason this pattern is obvious to people who implement ERP for a living.
An ERP system is what a company builds when it gets tired of losing state. The chart of accounts, the product master, the stock move, the timesheet: each one exists so that a specific question has exactly one answer at any moment. Thomas Davenport made the argument in Harvard Business Review in 1998 that an enterprise system imposes its own logic on a company's strategy and structure, and that companies which treat it as a technology project rather than an organisational one tend to regret it. That observation has aged well. Twenty-eight years later, roughly half of ERP implementations still overrun budget or schedule, and the reasons cited are almost never the software.
Melvin Conway's 1968 paper made the reverse point: the structure of a system ends up mirroring the communication structure of the organisation that built it. Both observations are now relevant to agent design, because an agent system is a small organisation, with all the coordination overhead that implies.
Odoo happens to be a useful place to see this clearly. Its ORM makes the state layer explicit: field declarations, model relationships, access rules, inheritance chains. The source code is the specification of what the business is allowed to express. An agent that reads the documentation is working from a description of last year's system. An agent that reads the code is working from the system.
The practices that are about to become engineering
We spent a century learning how to coordinate people who forget things and cannot share memory. A surprising amount of that knowledge is turning into engineering practice:
The handover note becomes a tool contract and a structured output schema. The decision log becomes a per-stage artefact that the next stage is required to read. The RACI matrix becomes one owner per data object, with everything else holding read access. Acceptance criteria become test cases fixed before generation, which is also the only reliable defence against scope creep in either an agent run or a consulting project. Change control becomes a versioned specification.
None of this is glamorous. It is the reason it works.
How this shapes the way we deliver ERP
Our own approach at GetConn.pro is a direct consequence of taking state seriously.
Discovery in traditional ERP projects is expensive because turning a described process into a configured system used to take weeks of specialist time. That cost is what forced the sequence: sign first, discover second, find out what you actually bought third. Everyone in the industry knows how that sequence ends, and it is why so many buyers arrive at their second ERP project with a specific kind of scepticism.
Agents change the economics of that first step. Configuration and realistic data population, the two slowest parts of building something a client can evaluate, are exactly the tasks that compress well. So we build the prototype first: a live Odoo 19 instance, configured for the client's actual workflow, populated with realistic records from their industry. The client logs in, runs their own process end to end, and finds the mismatches before there is a contract to argue about.
That is not a demo in the sales sense. A demo shows an interface. A prototype shows state: what the system will hold, who can see it, what happens when a real order moves through it. The claim we are willing to make is narrow and testable. See it working before you pay for it.
Where the analogy stops
Agents are not employees, and treating the resemblance as complete is its own failure mode.
A confused employee asks a question. A confused agent produces confident output. An employee who disagrees with a handover pushes back; an agent accepts a corrupted brief and proceeds. And more agents is very often the wrong answer: a single agent with well curated context and one clear owner of state beats a committee of five, for the same reasons a two person team frequently beats a matrix.
The market is starting to find this out. Gartner predicted in 2025 that more than 40 per cent of agentic AI projects would be cancelled before the end of 2027, citing unclear value and cost rather than model capability. A widely discussed MIT report the same year found that the large majority of enterprise generative AI pilots produced no measurable financial return. The pilots that did work tended to be narrow, owned by a specific function, and integrated with the systems that already held the company's data.
Which is the same finding, once more, in different clothing. The model is rarely the constraint. The organisation around it is.
Contact Us
We'd love to hear from you! Whether you have questions, feedback, or need support, our team is here to help. Simply fill out the form below, and we aim to respond to all inquiries within 24 hours. Thank you for getting in touch!
Frequently asked questions
Both, but the technical part is now the smaller half. Model selection, tool calling and prompting are well documented and increasingly standardised. What determines whether an agent system holds up in production is information flow, persistence of decisions and ownership of state, all of which are design problems that predate the technology.
Almost always because they hold separate copies of the same state. When two agents each act on their own snapshot of a plan, both act reasonably and the outputs cannot be reconciled. The fix is a single system of record that every agent reads from, plus explicit handoffs rather than implicit parallelism.
An ERP system is the organisational state layer made explicit. Every problem agent developers are currently solving, single source of truth, access control, audit trail, who owns which record, has a mature answer inside ERP practice. Teams that already implement ERP tend to recognise agent coordination failures on sight.
They speed up specific parts of it, primarily configuration and the generation of realistic test data, which is enough to move the first working prototype from months to weeks. They do not remove the need for business analysis, code review or agreed acceptance criteria. Anyone claiming otherwise is describing a demo, not an implementation.
Ask what the system reads as its source of truth, what it does when two instructions conflict, and what artefact each stage produces that a human reviews. If the answers are vague, the agents are decoration.