The task fit into a single sentence: which colleagues should be informed, and how, ten seconds after your meeting ends — and in which tools does the interaction get documented?
Two layers, no more. Sounds like an afternoon. It became a full day, and that day revealed more about our processes than the half quarter before it.
The interesting part was the line-up. Sales, marketing, project management and customer success took part. We deliberately did not field the development team as its own group but as floaters — they were allowed to help whenever something got stuck. A side effect we happily took: developers barely have meetings anyway. On the question “what happens after the meeting?” they would have been the worst witnesses.
Why did we deliberately keep the developers out?
Because once you have the right software in place, the question stops being a technical one.
Whether an agent can write a Slack message has been settled for years. Whether it writes it to the right person, at the right length, linked to the right object — only someone who would otherwise have typed that message knows that.
We expected the departments to hand in a rough wish list from which we would build a concept. The opposite happened. The approaches were more specific than anything development would have produced, because people modelled their own pain points instead of guessing at someone else's. Someone who forgets three times a week to tell a colleague about a commitment builds a different filter than someone who only knows the problem from a ticket.
That is the real yield of the format: a hackathon with non-developers is not a team event with pizza. It is a discovery method.
What did sales and customer success find out?
Both groups, without coordinating, proactively informed each other. That was the first sign that there was real pain here rather than a constructed one.
Their solution came down to two places: Slack (or Teams) for the notification and HubSpot as the CRM for documentation. Plus the decision that shaped the rest of the day — the meeting has to exist as a real object, linked to the right contacts. Not as a block of text stuck somewhere.
Three learnings from this group:
First: short, shorter, best. One to two sentences in Slack, maximum. No more. Meeting documentation looks different: two sentences plus bullet points. From that follows a rule that is harder than it sounds — every prompt for every output has to look different depending on whether you are informing or documenting. An agent with a single text template produces mediocrity for both cases.
Second: same system, different objects. Sales documents against deals, customer success against support tickets. Different objects, same substructure. That is why you have to understand the object relationships and feed them cleanly into contacts and companies — both build on those. Model that common ground badly and you have built two silos with an AI coat of paint.
Third: build in filters. When does anyone actually need to know? Not every interaction is worth a message.
Why were marketing and project management the harder case?
Because different systems are relevant there: task management, Google Drive with project documentation in Sheets and Docs, and the workflows and databases behind them holding things like campaign audiences or customer profiles.
Considerably more channels than sales and customer success. And at the same time considerably more stakeholders who need to be informed.
More complex — and in the end more useful. Every mention, every promise, every agreement gets passed on immediately. Exactly the thing that otherwise disappears between two calendar weeks.
The price became visible in the same session: you have to filter far more carefully who gets how much. A single catch-all channel would ping roughly every four minutes. Nobody reads that any more. Worse: nobody takes it seriously any more — not even when something important is in there for once.
How can you deploy AI agents without producing noise?
We condensed the approaches into one process that we start automatically through Motion. Motion is an AI-assisted work management platform that turns a prompt or a stored SOP into a project with tasks, assigns them by role and capacity, and schedules them itself. The built-in meeting notetaker provides the trigger; the integrations with HubSpot, Salesforce, Google Meet and Outlook provide the connection.
The process in five stages:
- Trigger — the meeting ends.
- Pass-through — the workflow finds every relevant object: CRM, task management, documentation, communication channel, whatever applies. Depending on the use case this differs enormously and each one is a completely separate workflow. That is not a blemish but the insight itself: there is no such thing as a generic post-meeting agent.
- Assessment by role and situation — based on six questions:
- What happened?
- Where do we stand?
- What should happen next?
- What is the output?
- What are the learnings?
- Who needs to be informed about what?
- Routing — into the right channel and the right tone.
- Proactive notification — the person gets the message without having to ask.
Documentation runs separately from this. In the CRM or task management you almost always need something different from the trimmed-down text block for Slack. At least two modes, often three: inform, document, different perspective.
How many automated messages can a team take per day?
That was the limit that surprised us most — because it has nothing to do with technology.
Our rule of thumb from the hackathon: between five and eight automated messages per day per recipient is where it gets critical. Above that, attention tips over and the channel is burned. From then on you have to split — by recipient group, by urgency, by object.
That is one day's experience, not a measurement series. But it matches what we have seen in production since: the capacity limit of an AI workflow is not the machine. It is the human at the other end.
Anyone planning to deploy AI agents in their company should set that number before the first automation, not after. Otherwise you are optimising a system nobody reads any more.
What happened to the prototype?
It was thrown away. As code, at least.
In one day the departments delivered a theoretically working version. That was exactly the task. But a hackathon result is a prototype — and a prototype is not a product. In the next sprint our development team rebuilt the workflow completely, optimised it and integrated it into the existing infrastructure.
What survived is the more valuable part: the requirements. The filter logic, the object model, the volume limit, the separation of informing and documenting. No development team would have made those decisions the same way, because they lack the day-to-day for it.
How do you run a hackathon like this yourself?
Six things that made the difference for us:
- Ask a question, not a task. “Who should know what ten seconds after your meeting?” can be answered. “Optimise our communication” cannot.
- Two layers, not ten. Informing and documenting were enough to fill an entire day.
- Developers as floaters, not as a team. Otherwise they solve the task instead of letting it be posed.
- Separate by department. The differences between sales and marketing are the actual insight. In mixed groups they average out and disappear.
- Demand something that runs. A slide deck produces no insight. Only the attempt to actually build it exposes what is missing.
- Plan the rebuild in. If no sprint follows the hackathon, it was a nice day and nothing more.
It was fun. Everyone learned something. Many had to step outside their usual remit. And even so — or precisely because of it — something deeper came out than a pure developer project would have delivered. Because the expectations and the approaches were formulated by the people who would later use the result.
Next step
You want to use meetings, not document them? We build exactly these kinds of processes — from the requirement through to production integration.
→ AI Operations at ReachOut Software — how we bring AI workflows into existing systems.
→ How we iterate safely without endangering production is described in Two systems, one deploy.
