What Archipel Labs is for

Pilots have flight simulators. Surgeons practice on models. Architects mostly have slides.

A slide works by removing detail. That is what makes it readable, and that is what makes it lie. The decision that costs you is always in the detail it removed: a data model imposed by a packaged product, a flow that cannot be event-driven, a word that two systems define differently.

Architecture deserves an experimental discipline. Archipel Labs exists to make architecture fail cheaply. Its test bench is TimberWorks, a simulated company that runs continuously. It has customers, orders, suppliers, and analytics. It also has enough imperfections to behave like more than a demo.

This company serves as three instruments: one for learning data platforms, one for testing integration patterns, and one for finding out what a company must be for AI to work inside it.

A living dataset for data platforms

Clean CSVs teach SQL. Contradictory systems teach judgment.

We treat data quality as a filling problem. Columns, formats, lineage. Tooling handles that half. The other half is architectural, and no tool does it for you.

TimberWorks makes its own mess, and it makes it in two ways. Some we design, to stay in control: a visitor's IP matches their home town only 80% of the time, so geolocation is wrong on purpose. The rest emerges by itself, out of the integration and the products we happened to choose. Nobody wrote it. It appeared.

The emergent kind is the one that grows up. Matomo counts a visit: one person, one session, in the browser. PrestaShop counts records: carts and orders, on the server. One visitor makes several carts, and a cart outlives the visit that created it. So a request for a conversion funnel comes back as two correct numbers that contradict each other, and no product can settle it.

What is a visit? No validation rule answers that. It takes a reference vocabulary and a golden source: an agreed definition, and one system allowed to be right about it. That is the judgment part, and it belongs to enterprise architecture rather than to data engineering.

It also cannot be repaired downstream. You will not fix in a lakehouse a definition nobody agreed upstream. So instead of inventing anomalies in SQL, you investigate the small lies that systems tell naturally.

A proving ground for integration patterns

Every company has an application map. Almost none can draw its flows.

I find that backwards. The flows are what make an information system dynamic: a clean, decoupled integration layer is what lets you replace a packaged application, adopt a new technology, or change a business process without redesigning everything around it. It is the most critical system in the company, the least mapped, and the one nobody dares touch.

So Archipel Labs makes those arrows real. And the position I want to defend is that knowing the patterns is not the skill. That catalog was settled long ago: Hohpe and Woolf published Enterprise Integration Patterns in 2003, and its vocabulary still describes what we build today.

The difficulty is that packaged software constrains you far more than ordinary development does. It decides which flows are even available to you, and what shape your data arrives in.

PrestaShop has no outbound webhook for the changes we need, so a simple event-driven design is off the table. We poll, compute a delta, or reconcile the full state. Even in a fake company, the architecture must bend to the product.

From there you can go fast or go deep, and the lab exists to show what separates them. Fast is a workaround: read someone else's tables directly and move on. Deep means refusing that, and paying for it. Capturing change events at the source, carrying a business model that belongs to no product, and then finding out what your decision costs in latency when the business is running.

Apache Camel carries these flows today. Tomorrow the same case could be rebuilt with MuleSoft, NiFi, an iPaaS, or plain services. It is a strange field: proprietary vendors, open-source alternatives almost nobody has heard of, and a lot of companies quietly building their own. The product can change without changing the lesson.

A test bench for AI in an information system

The agent is the instrument. The company is the subject.

Almost everyone building with agents today treats the agent as the subject of the experiment: a stronger model, a better harness, one more tool, until the benchmark finally passes. The company it works in is just the fixture. That tells you about a vendor, not about your company. And it ages badly. The engineering around agents moves fast and none of it is yours: whatever you build this quarter to squeeze more out of a model stands a fair chance of being obsolete, or free, within a year.

Work on the information system does not expire that way. Agreed definitions, evidence you can reach, access rights that make sense: those pay off with or without AI, and they pay off more the earlier they are done, because they are what an agent eventually has to be wired into.

The urgency is not picking the right model. It is making the company legible, and starting soon.

Archipel Labs runs the experiment the other way round. The agent never changes; the company around it does. Give the agent a business incident and read-only access, and see whether it can detect the problem, find the cause, and recommend an action. Then change the company. Better indicators. Different access. A second role to work with. Run the same incident again.

Everything that moves is then a property of the architecture, not of the model. Was the monitoring enough, and how much of it was noise? Treat the agent as an employee and two more questions open up. Do its permissions reach the evidence without handing it the whole company? Does its job description cover what the company needs done? Neither answers the other, and both become experiments instead of opinions.

We ran the first one for real. One carrier row deleted from a supplier feed, no error anywhere in the system, and an analyst asked to explain a few customer complaints. What surprises me is not whether it succeeds. It is how often the answer lands outside the frame I had in mind. That is what you want from an instrument, and never what you want from a demo.

None of this replaces integration. An agent sits on top of the flows, and those still have to be minimal, algorithmic, and controlled. What is new is that a company can be asked a question, and how good the answer is turns out to be a property of the business itself.

One company, three instruments

One company. Three instruments. Data that contradicts itself, integrations that resist, and a company that has to be readable enough to answer a question.

Archipel Labs creates just enough reality to make architecture testable. What comes next is not a list of technologies to adopt. It is what a company does next: open a second shop, hire, get audited. Each brings its own systems, and each becomes an experiment. The roadmap is the biography of a company that does not exist.

Explore the lab, inspect the code, or get in touch.