There is a company in Berlin called Agent F that raised $4 million in pre-seed last week. The team has ten people. The lead investor was Alpha Edison, with United Founders and Tiny Supercomputer Investment Company participating, and the angel list includes n8n founder Jan Oberhauser, wefox co-founder Julian Teicke, and former SAP CTO Jürgen Müller.
What it sells sounds like ERP, but the way it is described is different. Traditional ERP implementation is 'mapping your processes into modules'—requirements research, configuration, development, testing, and go-live, a long chain. Agent F's description is: the system learns the customer's existing classification habits, approval rules, and reporting logic, and modules are added as the business grows.
In an interview with Tech.eu, there is a figure: administrative work that originally took five or six hours per week dropped to about one hour. But the company did not disclose the client names, nor did it disclose the number of clients.
Looking at these two things together—on one side, 'no configuration, learn instead'; on the other, 'results have numbers, but customers have no names'—you'll find that AI entering ERP has long since stopped being a single path. Today there are at least three approaches, and the dividing line between them is not the strength of the model, but the same question: Can this thing be replicated to a second company?
I. Three Paths, Three Failure Modes
For the past two years, people have discussed "AI in ERP" as one issue, but in fact it has already branched. The three paths are completely different in how they start, where the money is spent, and what failure looks like.
| Path | How to start | Where is the money mainly spent? | What does failure look like |
|---|---|---|---|
| Project-based configuration | Streamline processes, configure modules, perform secondary development when necessary, then train and go live | Person-days. Research, configuration, development, data migration, acceptance. | No one uses it after launch; or every time there is a minor policy adjustment, it has to be rescheduled. |
| Learning-based adaptation | Connect to existing banking, accounting, payment, and business tools, and learn categorization and approval habits from historical operations | Product subscription plus a small amount of implementation; theoretically, implementation is lighter. | Every customer has to be taught again, and adaptation becomes another kind of customization. |
| Platform-based leasing | Built uniformly by the park, platform, or service provider, with enterprises accessing on demand | Subscription fees or credits, allocated based on usage | Unclear data boundaries, uncontrolled point counts, and scenarios that are launched but maintained by no one |
The first path is the most familiar, and also the easiest to be criticized. But it has an advantage others cannot match: every step leaves a trace. How the process was sorted out, who set the rules, and what was changed are all in the documents and configurations. If a problem arises, it can be checked; if someone else takes over, they can understand it.
The second path is the most tempting. The low disruption it promises is real—no need to shut down operations for half a year for implementation, no need to break processes into dozens of modules. But it moves complexity from the "configuration stage" to the "operation stage": the rules are hidden in the model's judgments, not in configuration tables. This brings up the second question.
II. The real test question for learning-based adaptation: If a different person triggers it, will the result be the same?
On November 11, 2026, SAP News published an interview with Sonja Liénard. She is Senior Vice President at SAP and head of the ABAP Platform. The most quotable line in the entire interview is not a vision like "agents sit in front of applications," but what she said when discussing reliability:
Data and results must always be reliable, traceable, and reproducible—no matter who triggers the agent or which path it took to obtain the data.
She added one more sentence: every agent must have a clearly defined scope of authorization. Taken together, these two sentences are precisely the acceptance test for “learning-based adaptation.”
Because learned rules are implicit. Implicit rules have three problems:
- When a problem occurs, it's hard to say which judgment caused it; you can only see that the result is wrong;
- The same person running it twice may give different answers, especially in edge cases;
- Switch to another entry point—change email to chat, text to voice—and the result changes yet again.
This is not nitpicking. Financial posting, purchase ordering, and inventory adjustments—these actions themselves require 'the same input to produce the same output.' Humans can handle things flexibly based on experience; machines cannot, because machines are not embarrassed when they make mistakes—they just repeat them.
| Test Action | How to test | What do the results indicate? |
|---|---|---|
| Change trigger person | The same historical document, initiated separately by two employees | The inconsistent results indicate that the judgment depends on personal operating habits rather than rules. |
| Switch entrance | The same content, submitted separately via email, chat, and voice | The discrepancy goes beyond the channel itself, indicating that the system made a guess during completion. |
| Rerun at intervals | Three months later, when the model is upgraded, run the same batch of documents through again | The difference list cannot be explained item by item, indicating that the upgrade had no regression testing. |
So the third requirement can be made concrete: have the vendor take the same batch of historical documents, have a different person trigger it and submit it through a different entry point, and see whether the field-level results are consistent; after the model is upgraded three months later, rerun the same batch of documents, and can the list of differences be explained item by item? If it can be explained, it means the rules are clear; if it cannot be explained, it means the system is guessing on your behalf.
Here's a counterintuitive point: “learning fast” and “learning steadily” often pull against each other. The more you rely on historical data to automatically generalize, the more likely you are to learn one-off operations as rules—a particular exceptional approval, a temporary discount for a certain customer, a certain buyer's personal habit. Looking back three months after launch, you'll find that you've turned a bunch of exceptions into the standard.
III. Renting This Path: 87 Enterprises Share One Set of Intelligent Agents
On the same day, the government website of Hanshan District, Handan, Hebei, published a message about the “Smart Chain Hub” AI agent platform at the Zhijiang Smart Logistics Park. The park has a planned area of about 200 mu, 87 resident enterprises, and a total output value exceeding 3 billion yuan in 2025.
What the platform does is not complicated: it connects the ERP, WMS, finance, and energy consumption systems already in use by enterprises in the park, uses natural language as a unified entry point, and turns business data, paper documents, and equipment operating status into things that can be conversed with and computed. In the first phase, it implements six agent scenarios: decision support, contract and finance, inventory ledger, processing ledger, intelligent equipment monitoring, and AI safety supervision. Management personnel can retrieve data through conversation, generate business dashboards, and conduct contract risk control, inventory reconciliation, and document digitization.
The subsequent plans are even more noteworthy: train vertical large models for the park, create "digital employees" such as dispatchers, document clerks, and business specialists, and open the AI capability platform to the outside to provide services to resident enterprises and OPC entrepreneurial entities.
This path may be the most realistic for China's SMEs. A company with a few dozen people cannot afford a team that can handle agent orchestration, permission management, and model invocation; but if the park builds one unified system, marginal costs immediately drop. What it solves is not "how powerful AI is," but "who will operate and maintain it."
The cost is also clear: if any one of the three things is not well designed, the platform will not last long:
| Hard constraints | Specific Issues | Consequences of not doing it well |
|---|---|---|
| Multi-tenant isolation | The inventory ledgers, contracts, and processing records of 87 enterprises all run on the same platform | Company A asks one question, "How much was shipped this month?", and the answer gives Company B's figure. |
| Identity and Authorization | Whose identity does the agent use to retrieve data, and which position's permissions does it inherit? | Set permissions too broad and the whole family can see it; set them too narrow and it errors every day. |
| Measurement and Allocation | How are points, computing power, and call counts calculated for each enterprise? | Those who use a lot don't pay, while those who use little are charged a high share; the second batch of enterprises then won't come. |
It should be noted that this press release did not disclose the platform provider, launch time, actual number of enterprises connected, or charging model. The 87 enterprises and RMB 3 billion are existing data for the park, which do not equal the number of enterprises that have already used the platform. To judge whether this path succeeds or fails, we still have to wait for operational data.
IV. How to Choose: Three Questions, One Cost Table
None of the three paths is absolutely superior or inferior, but the cost of choosing wrong is different. If you choose the project-based approach wrong, you lose time and person-days; if you choose the learning approach wrong, you lose by packaging customization as a product; if you choose the rental approach wrong, you lose on data boundaries and long-term lock-in. So the order in which you ask questions matters.
First question: How much has to be redone to replicate this for the second customer?Don't ask "Is there an industry template?" A template addresses "roughly how this industry operates," but not "what this company looks at first when it encounters this document." What you should ask is how long the second customer's list of differences is, and who will make that list.
Question 2: If you change the person or the entry point, will the result be the same? This is the reproducibility test mentioned above. Don't just look at the demo—the demo is always the prepared path. Take real documents and have different people run them once through different entry points, then look at field-level differences.
Third question: When something goes wrong, can you clearly say which rule caused it?Only readable rules can be changed; if rules are not readable, the only option is retraining. The cost of retraining does not disappear—it is merely shifted from this year to next year, and is often higher—because by then the business already depends on it.
There is another table that is often overlooked: total cost must be compared on the same basis.Project-based pricing is calculated by person-days, learning-based pricing by subscription plus implementation, and platform-based pricing by points or allocation. First-year quotes in these three pricing units cannot be directly compared. At minimum, look at three years: whether person-days will be added as policies change, whether subscriptions will rise with user count, and whether points will spiral out of control with usage. The one that is cheapest in the first year is often the most expensive by the third year.
Three for Managers
First, write "reproducibility" into the acceptance criteria, rather than "accuracy." Accuracy is the quality of a single result; reproducibility is a property of long-term operation. The former can be demonstrated, while the latter can only be measured through replay. Writing "for the same batch of historical documents, rerun through a different entry point, and every field-level difference must be explained item by item" on the acceptance form is far more useful than writing "accuracy of no less than 95%."
Second, keep a separate ledger for exceptions. Every temporary rule of “this time is special, let’s do it this way for now” must be recorded: who approved it, why, and how long it is valid. Looking back at this list three months later, you will clearly know how many rules in the system are actually personal favors. If you don’t keep this ledger, learning-based adaptation will sooner or later learn the wrong way.
Third, if it is a rented platform, first ask for a data boundary map, then discuss the scenario list. A scenario list may look impressive, but data boundaries determine whether it can be used. Ask three questions: where is my data stored, who can see it, and how do I take it with me when I exit. For platforms that cannot answer clearly, no matter how many scenarios there are, don't rush.
Let's go back to that Berlin company from the beginning. Ten people, four million dollars, and a promise to "learn your workflow"—none of that is enough to judge success or failure. The real test comes when it lands its eleventh customer: does it need to send a consultant on-site for three months? If yes, then what it's doing is still project-based work; it has just replaced the configuration interface with a dialog box.
One-sentence summary: Models change a generation every three months, but processes and standards won't grow on their own. Which path to choose ultimately doesn't depend on how smart the model is, but on whether this path can produce a second and third company—and still run just as steadily.
Sources: EUVC, “Agent F raises $4m pre-seed for AI-native ERP” (2026-11-10, including Alpha Edison leading the round, United Founders and Tiny Supercomputer Investment Company participating, the angel investor list, integration scope, and the wording “learning workflows”; the original source includes Tech.eu’s 2026-11-10 interview with founder Felix Schläger); SAP News interview (Johannes Klostermeier interviews Sonja Liénard, Senior Vice President and Head of ABAP Platform at SAP, 2026-11-11); Handan City Hanshan District People’s Government website, “New Practices in Smart Logistics! AI Agents in Hanshan District Help Enterprises Break Through and Upgrade” (2026-11-11, including park scale, six major agent scenarios, and subsequent digital employee plans).
Data basis note: Agent F's 'five to six hours per week reduced to about one hour' comes from a Tech.eu interview; the company did not disclose customer names or numbers, so this figure cannot serve as an industry benchmark; the SAP interview reflects the vendor's viewpoint and contains no performance data; the 200 mu, 87 enterprises, and 3 billion yuan output value in Hanshan District are existing park data, while the press release did not disclose the platform supplier, launch time, actual number of connected enterprises, or charging model; this article uses them only for path judgment, not as evidence of implementation results.
Zodioo · Enterprise Digitalization Insights · 2026-11-12
