Case study · AI systems: agents, teams and results
Case: a market study with six AI agents in parallel, one capture day and a datum-by-datum audit
Sebastián Ocampo · 2026-07-25
We wanted to know what the European market really asks for when it hires AI leadership, and no study cited literal postings. So we did it ourselves: this is the system with which a one-person team produces auditable market research in days, not months. Everything this case claims can be rebuilt from the dataset.
- 6 Research agents in parallel, one per market segment
- 83 → 79 Postings captured in one day → in-scope rows after cleaning and deduplication
- 2 Publication-blocking errors found by the independent audit before publishing
The problem: a market that refuses to be read
The question was concrete: what do Swiss and European companies ask for in writing when they hire AI leadership? Not consultancy opinions or perception surveys: the literal responsibilities, KPIs, reporting lines and salaries of real postings. That evidence did not exist published, and producing it by hand is weeks of work: finding dozens of live postings in four languages, extracting more than twenty fields from each, keeping the provenance of every datum and contaminating nothing with memory or assumption.
And there was an obstacle worse than volume: the sources defend themselves. Swiss job board search pages and LinkedIn block automated access, so the obvious route (a classic scraper over the listings) was closed, and the lazy route (asking a model "what does the market want") would have produced exactly the kind of sourceless report we wanted to avoid. We needed a system that browses like a researcher, extracts like a database and answers for itself like a data scientist.
The system: six agents, one data contract
The design splits the market into six segments (Swiss leadership, DACH leadership, transformation, finance and operations, marketing and growth, Benelux with the Nordics and France) and launches one research agent per segment, in parallel. Each agent browses company career pages, public ATS systems and accessible job boards, and delivers its findings in one JSON file per segment under the same schema. The full capture happened in a single day.
Reliability does not live in the agents but in the contract they sign. Three extraction rules: text fields are copied verbatim from the posting (responsibilities, KPIs, salary exactly as displayed), whatever is not visible stays empty instead of being estimated, and every row carries the URL where the posting was seen, with job-board mirrors labeled as such. After merge and deduplication, every statistic in the study is computed from a written definition frozen in a results file, so any figure can be recounted from the dataset without asking anyone. The full flow, from brief to publication:
- Brief and definitions
- Six agents in parallel
- Extraction into 22 fields
- Merge and deduplication
- Frozen statistics
- Independent audit
- Documented corrections
- Publication with sources
The decisions: why this and not that
Every piece of the system displaced a concrete alternative. This table is the part of the case most worth stealing: not the tools, the whys.
| Decision | Discarded alternative | Why |
|---|---|---|
| Six agents in parallel, one per segment | A single sequential agent | Parallelism turns weeks into a day, and the per-segment split gives each agent a small, coherent context: less confusion, better extractions. |
| Verbatim extraction into structured fields | Agent-written summaries | A summary blends what the posting says with what the model expects it to say. Verbatim text can be checked against the source; a summary cannot. |
| Empty cell when the datum is not visible | Letting the model estimate or fill in | It is the cheapest anti-hallucination rule there is: an honest gap can be filled later; an invented datum poisons every statistic that touches it. |
| Every statistic's definition frozen in a file | Counting on demand each time it is cited | Without a frozen definition, the same question yields different numbers depending on who counts and when. It genuinely happened to us: see the failures section. |
| Audit by an independent system before publishing | Trusting the pipeline that produced the data | Whoever produces a datum should not be the one approving it. The independent recount reproduced every figure and caught two errors that would have shipped. |
| Source URL on every dataset row | Dataset without per-row provenance | Per-row provenance is what separates a citable study from an opinion with a table: any reader can go to the posting and check. |
The honest accounting: what it cost and what we did not measure
The verifiable part: the full capture (83 postings, six segments, four source languages) happened in one working day with the six agents in parallel, inside already-paid AI subscriptions, with no incremental platform cost. The independent audit added a second pass over the dataset. The manual equivalent of just the capture and extraction (dozens of postings read field by field in German, French, English and Spanish) is weeks of work for one person; we do not publish an "hours saved" figure because we never operated that manual process as a baseline, and estimating it from memory is exactly what this system forbids.
What we did not measure, and it is the most useful failure to tell: we did not log this run's token consumption, so we cannot publish a cost per extracted posting, and we will not invent one. The lesson is already applied: the corpus scale-up to 150-300 postings will run with token and agent-hour metering from the first minute, and that number will be published here. The method for turning tokens, subscriptions and supervision into cost per unit is in the content operation blueprint's calculator; it was missing its input datum, and that is the moral: instrument before you run, not after.
The result, and how it was measured
The result is a dataset of 79 in-scope postings (of 83 captured), with 22 fields per row, 74 rows extracted from the posting's full text and the remaining 5 marked snippet-level, per-row provenance and a statistics file with frozen definitions. The measurement criterion was external by design: every headline figure was independently recounted against the raw dataset, and publication stayed blocked until all of them reproduced. All did, after two corrections (told below), and the wording rules are written down so figures do not warp as they get quoted: for example, 38 of 79 postings "demand measurable KPIs", which is not the same as "demand ROI", and the difference matters.
The dataset is already producing pieces: the blueprint for hiring a Chief AI Officer comes entirely out of it, as does the atom what does a Chief AI Officer do. The full study will be published once the corpus grows to 150-300 postings under the same definitions. That is the other half of the result: reusable research infrastructure, not a throwaway report.
What failed
Four real failures, each with its fix, because an empty failure log only means nobody writes things down. One: a compliance false positive. Searching for the string "AI Act" flagged a Swiss posting that actually said "AI activities"; the automated count showed two postings naming the European law when the real figure is one. The audit caught it by reading each match in context, and the rule is now written: every string match gets verified in context before being counted.
Two: the country field mixed formats ("CH" and "Switzerland" on different rows), so per-country counts did not match the published statistics until a normalized country-code column was added. Three: one headline figure (24 Head of AI titles) was not reproducible because its definition lived in the head of whoever counted it; it had to be frozen in writing (titles beginning with Head of AI, Head of Artificial Intelligence or Head of Data & AI: 22 plus 0 plus 2) so any future recount lands on the same number. And four: blocked job-board search pages bias the sample towards employers with public ATS pages, and 5 rows only reached snippet level. That bias could not be removed; it could be declared, and it is, in the methodology and in every piece that uses the dataset.
Data governance: the rules that did the rest
The whole system hangs on integrity rules written before the first agent launched: no posting gets invented or embellished; every row keeps its URL; mirrors and estimates are labeled on the row itself; out-of-window or out-of-region rows stay in the dataset marked out of scope, rather than deleted, so the cleaning is inspectable; and the definitions and wording rules travel with the data so figures do not mutate as they get quoted. It is the same governance we apply to everything this house publishes, applied to research: agents do the work, rules decide what counts as truth, and a person signs.
The practical consequence for any company: this level of rigor does not make the project more expensive, it makes it cheaper. The audit's two corrections cost hours; the same error found by a reader after publication would have cost the whole study's credibility. In agent research, governance is not the brake: it is what turns speed into something publishable.
How to replicate this research sprint in your company
The same pattern works for any market question living in scattered public sources: what your sector's tenders ask for, what competitors promise on their product pages, what regulators require in each country you sell in. Six steps:
- Write the question and the schema before any prompt One concrete question and one empty table: which fields each row will have, which are verbatim and which computed. If you cannot draw the empty table, you do not yet know what you are researching.
- Write the integrity contract Three minimum rules: verbatim or empty (never estimated), source URL on every row, and every anomaly labeled on the row itself. This document matters more than the model choice.
- Split the ground into segments and launch one agent per segment By geography, language or category: whatever produces small, coherent batches. Each agent delivers in the same schema. The parallelism is what compresses weeks into a day.
- Instrument the run from the first minute Log tokens, agent time and human review hours as it happens. It is the step we skipped, which is why this case cannot publish its cost per posting: learn from our gap.
- Freeze the definitions and compute the statistics once Every figure you will quote gets defined in writing and computed against the dataset, with the result stored in a file. From then on, everyone cites the file, nobody recounts from memory.
- Have it audited by someone who did not build the pipeline Another person or another system recounts every headline figure from the raw dataset, with publication blocked until all reproduce. Budget half a day: it is the cheapest insurance in the project.
Where this evolves (as read in July 2026)
The immediate part is already decided: growing the corpus to 150-300 postings under the same frozen definitions, token and hour metering from the first minute, and publishing the full study with the open dataset. The structural part is more interesting: research agents improve every quarter at browsing and at languages, so the cost of repeating this sprint falls while its value rises, and that turns market research into something you re-run every quarter instead of commissioning once a year. The competitive edge shifts from access to the data (which gets cheap) to what almost nobody is building: the integrity contract, the frozen definitions and the independent audit that make an agent-produced dataset citable. Whoever has that infrastructure will publish evidence while their competitors publish opinions.
This case is the second production system documented in this lab, after the editorial operation with agents. The general framework, in AI systems.
Frequently asked
- How do you stop the agents from inventing postings or data?
- With the contract, not with trust: text fields are copied verbatim from the posting, anything not visible stays empty instead of being estimated, and every row carries the URL where the posting was seen, so any row can be verified against its source. On top of that, an independent audit recounted every headline statistic against the raw dataset before use. It found no invented rows; it found two counting errors, which is exactly the kind of failure that design exists to catch.
- What did producing the dataset cost?
- One capture day with six agents in parallel plus one audit pass, inside already-paid subscriptions and with no additional platform cost. The exact token cost we do not know, because we did not meter this run, and we would rather tell you that than invent a figure: the 150-300 posting scale-up will run instrumented from the first minute and its cost per posting will be published. To estimate such a project for your company, the cost structure (tokens, subscriptions, human supervision) is broken down with a calculator in the content operation blueprint.
- Why agents and not a classic scraper?
- Because the job was not downloading pages but reading them. The sources were heterogeneous (company ATS systems, job boards, career pages in four languages), many block bulk automated access, and the value lay in extracting semantic fields (verbatim responsibilities, reporting line, salary nuances like "overpayment depending on experience") that a selector-based scraper does not understand. An agent navigates irregular sources and extracts meaning; the integrity contract and the audit remove the risk it brings in exchange. For uniform, stable pages a classic scraper is still cheaper: this was not that task.
- Can my team replicate this without developers?
- The pattern yes; the initial ambition should be smaller. With a general-purpose agent tool and no code you can run the small version: one question, one table schema, the integrity contract (verbatim or empty, URL per row), two or three agents per segment and one person recounting the figures before use. What does require craft is the frozen-statistics and scripted-audit phase. Start with the small version on a question you care about; if the result changes one of your decisions, you know the instrumented version is worth building.
- When will the full study be published?
- When the corpus grows from 79 to between 150 and 300 postings under the same frozen definitions, the same audit and an instrumented run. Publishing the pilot as if it were the study would have been faster and worse: the pilot sample already feeds pieces that cite its size and biases honestly, and the study will ship with the open dataset so anyone can recount it.
Sources
- How we built our multi-agent research system · Anthropic · 2025-06
- Building effective agents · Anthropic · 2024-12
- AI Risk Management Framework · NIST · 2023
- El blueprint construido con este dataset · y8y.ai · 2026-07
More cases and the method, in AI systems: agents, teams and results.