Methodology
·
5 MIN
Building event-scout: an agentic micro-app that runs unattended
We built a small tool that scouts B2B events for us and runs on its own. The lesson is the shape, not the events.
LOCATION
Remagen, Germany
SERIES
Case Studies & Tips
AUTHOR
Aashwin Shrivastava
PUBLISHED
We built a small tool, event-scout, that scouts business events near us, ranks them for the kind of relationship-led sales we do, and then runs on its own. This is a case study of our own build, so read the numbers as ours, not a benchmark.
The point of the piece is not the events. It is the shape. event-scout is an agentic micro-app: something you build once with a coding agent and then leave running, where the agent does the messy judgment and plain scripts do the boring, repeatable plumbing. That split is the whole lesson, and it travels to nearly every internal task a Mittelstand team keeps doing by hand. event-scout runs on the highest of those layers, an agentic CLI (iiterate).
01.
What it does, concretely
Once a run, event-scout works through a curated source database of event sites, calendars, newsletters, and a few LinkedIn feeds. From everything it fetches, it keeps only in-person, future events within reach of Remagen, scores each one for how useful it is to us, removes duplicates into a single store, and rebuilds a dashboard we actually open.
Little about that list is novel on its own. What makes it work is that it runs unattended on a schedule, and that the judgment it applies is ours, not a generic relevance filter. The output is not a feed of every tech event in Germany. It is a short, ranked answer to one question: where should we show up next.
02.
The shape that made it work: agent for judgment, scripts for plumbing
The design decision that matters is where the model stops and a script starts.
Fetching is delegated to a deterministic helper. A small Node orchestrator renders each due source in a real headless browser, so it handles JavaScript pages, light anti-bot walls, and lazy-loaded lists, and it captures structured schema.org event data when a page exposes it. That is plumbing: reliable, cron-able, and the same every time.
The agent reads what the fetcher saved and does the parts that resist hard-coding: pulling real events out of messy pages, deciding what counts as in-person and relevant, scoring each one, and spotting that two listings are the same event. A second small engine then merges, prunes old entries, and regenerates the dashboard.
🔸 Do not make the model do what a script does cheaply.
Rendering a page and writing a file is deterministic work. Handing it to the model would be slower, costlier, and less reliable.
🔸 Do not make a script do what needs judgment.
Whether a half-formatted listing is a real, relevant, in-person event is exactly the call a model is good at and a regex is not.
Getting that line in the right place is most of why the tool is dependable rather than a clever demo.
03.
It tunes itself
A scout that checks every source equally every run wastes most of its effort, because events do not appear evenly.
So each source carries its own short yield history. Sources that reliably produce relevant events are checked every run. Sources that keep coming back empty back off onto a growing cooldown, a week, then two, then a month, and are re-tested after it expires rather than dropped. A source that simply rendered no events is quietly deprioritised; only a source that fails to load several times in a row is retired as broken.
The effect is that attention flows to where events actually show up, and it adjusts itself over weeks without anyone tending it. That self-tuning is what makes unattended a real claim and not a hopeful one.
04.
Opinionated scoring beats a generic feed
The score is deliberately ours. Each event gets a value out of 100, weighted for our situation: how near and easy to reach it is, how densely the room holds the kind of buyers we serve, how intimate it is, whether there is a concrete lever such as a discount or a speaking slot, and how soon it is.
The weighting carries an opinion we hold about sales. A large conference ranks high only when there is a real lever to use, because for relationship-led selling a crowded hall with no way in is worth less than a small regional roundtable where we can actually talk to people. The result reads as a decision cockpit rather than a calendar: it points at where to spend a day, not at everything that exists.
A generic event feed could not encode that, because the judgement is specific to how a particular team wins work. That specificity is the reason it was worth building rather than buying.
05.
Why a micro-app, not a SaaS
event-scout is small on purpose. The whole thing is a handful of JSON files for the sources and the event store, a couple of scripts, and one self-contained HTML dashboard that opens straight from disk. There is no database to run and no subscription to renew. The data stays ours, and so does the scoring.
This is the same move Anthropic's own non-engineering teams have described, building small internal tools with a coding agent instead of filing a request and waiting (claude.com). We have written about that pattern from the user side too (iiterate).
It is not free of rough edges, and pretending otherwise would be dishonest. Login-walled sources need a session captured by hand once. A few stubborn sites stay manual leads rather than fake results. And we verify each rebuild by checking the page's structure directly, because a screenshot stalls on a font load. None of that changes the conclusion: when a task is repeatable and specific to how you work, a coding agent can turn it into a small owned tool for less than the SaaS or the manual hours it replaces. The harder question is not whether you can build one. It is which of your weekly chores has been quietly waiting to become one.
