In August 2026 I ran an agent hackathon for the Data#3 Marketing Team: four groups of four, two and a half hours, synthetic data only and no production systems anywhere near it. The people on the tools were campaign managers, content leads and events staff rather than IT, which I saw as a great opportunity because agent building has moved to the people who own the work, but the governance conversation has not moved with it.
The session was structured to test a simple idea: a good demo is not enough. A successful demo can show that an agent works, but it tells you far less about what happens when sources disagree, permissions are too broad, or somebody asks a question you were not expecting.
By that point I was already confident the team could build agents. What I wanted to understand was whether we were asking the right questions before putting them in front of other people.
The exercise was deliberately structured to mirror the way agents are often built in practice. Each group received an introduction to agents and the four gates, followed by two use cases and a project brief. They then had forty minutes to build a solution before stopping to review their work, harden the design and demonstrate what they had learned.
To make the exercise realistic, I handed the team a deliberately flawed instruction set labelled version 0.9 and described as a first draft from a colleague who meant well. The instructions were to build exactly what was written and fix nothing during the first sprint. While that constraint sounds artificial, the behaviour it was designed to test is not. People regularly discover an instruction set in a post, a forum, a workshop or a colleague’s experiment, copy it into a tool and see what happens. The exercise simply made that habit visible.
The biggest takeaway for me wasn’t actually the build itself, but the review process. It challenged us to look beyond whether an agent works and think more about governance and risk. It really shifted my mindset from ‘Can we build this?’ to ‘Should we build this, and what needs to be in place before we do.
Amanda Gower – Marketing Specialist, Data#3
The hidden payload travelled through the normal workflow of a person in a hurry. The instructions lived behind a copy button on the hackathon site, the full block was longer than the visible page suggested, and the Copilot Studio field showed only the first part of the pasted text before scrolling to the bottom. Nobody scrolls back through a box they have just filled, which meant each group shipped a buried mandate they had never seen on screen through their own hands using an everyday workflow.
The mandate itself was deliberately silly, forcing the agent to write “Coostomer”, “Werkshop” and “Wobinar” in otherwise polished copy. Groups spotted the symptom quickly and most assumed the model was broken, but almost all of the investigation focused on the visible instructions rather than the path those instructions had taken to reach the system. I expected at least one team to trace the issue back to the copy-and-paste process during the first sprint. None did, which was revealing because the payload was harmless. A copy-and-paste path that can smuggle in a spelling joke can just as easily smuggle in an approval bypass, an instruction to suppress a caveat or a rule that quietly marks output review complete. That being said, making mistakes is part of learning how to work with any new technology, and I’d much rather uncover them in an exercise like this. It gives teams the chance to see where their assumptions and everyday working habits can let them down, and learn from those mistakes before they happen in a real environment.
After an hour or so everybody stopped building and changed jobs, with the people who had assembled the agent now asked to review it from a different perspective and assess the decisions they had made during the build. That reflects the reality of most projects, where teams are often reviewing work they produced themselves while they still remember why each decision felt reasonable at the time.
What I found most interesting during that review phase was how quickly the conversation changed once people stopped defending a build and started assessing it. The agents themselves had not changed, but the questions people asked began to. Decisions made in the interest of speed attracted more scrutiny, assumptions that had gone unchallenged during the build became easier to spot, and controls that had felt unnecessary forty minutes earlier suddenly seemed easier to justify. Most technical leads will recognise the pattern. Governance reviews rarely fail because people do not care about risk. More often, they fail because the people reviewing the design are still too close to the decisions that created it.
By the time the review phase began, teams had started uncovering flaws in the agents they had built. What interested me was less whether they could find problems and more how they responded once they had found them. The scoring system was designed to make that visible by placing a higher value on controls than prompt changes and a higher value on missing safeguards than visible mistakes.
A planted flaw, correctly described and tied to the line that caused it, was worth ten points. Mapping it to the gate it broke added five. Proposing a fix that was a control, meaning a changed setting, a removed permission, a deleted source, or an approval step the agent could not bypass, added ten more. Proposing a fix that was only different prompt wording added three. A silent omission, meaning a control that should have existed but did not, was worth fifteen.
The gap between ten points for a control and three points for a rewording was deliberate because teams are used to trying to solve weak design with better instructions because that is the fastest thing in front of them. An instruction is a preference and a permission is a control.
The fifteen points for a silent omission mattered even more. Missing controls are harder to spot than visible mistakes because there is nothing in front of you to react to. You have to know what should have been there and notice its absence. No named approver. No source-of-truth decision. No record of what the agent told whom and when. No review step by someone other than the builder. Those are the gaps that let polished failures reach other people.
“It runs” was only a fraction of the showcase rubric. Scaffold quality outscored the fact that the agent could answer a question.
Three moments from the exercise stayed with me because they kept resurfacing in the debrief and in the conversations that followed.
The first involved the hidden copy-button payload. Nobody in the room pasted instructions they had read in full, and no step in their workflow would have caught the buried mandate. Every group carried the instruction into their build through their own hands using a process that felt completely normal at the time. The risk was not the payload itself, but how effortlessly it travelled through a workflow that nobody thought to question.
The second came from a controlled two-engine experiment. We ran two groups per use case with word-for-word identical instructions, changing only the underlying model. The outcome was exactly what I expected, but it was still useful to demonstrate in the room. The model changed which flaws surfaced during a forty-minute build and changed none of the flaws that were there.
A stronger model can cover for weak design in a workshop. It might volunteer a caveat, refuse a risky action in conversation or explain its date handling more clearly. That can create the impression that the build itself has improved, even when the underlying weakness remains untouched. Swap the model, change the task or move from chat to an artefact and the same fault can surface again. One practical lesson carried well beyond the workshop: a model change is a change, which means the evaluation needs to be run again before anybody relies on the result.
AI isn’t magic. It’s acting on the data we provide. So, the first thing our team did was assessed the raw data provided in the exercise. We we’re quick to identify the variations in DD/MM/YYYY, missing columns that could incorrectly affect returned queries, and turned off external data (internet) access entirely. By creating a loop where the Agent could only return data from our limited pool, it made assessing the viability of the outputs it created much easier.
Hugh Whitehouse – Senior Video & Multimedia Producer, Data#3
The third example produced the clearest illustration of why transcripts can flatter a design. In the campaign scenario, one of the planted faults forced American-style numeric dates into an Australian context. During the chat interaction, a strong model recognised the source format, converted the date correctly and explained what it had done. If you only reviewed that exchange, the issue appeared to be contained. When the same model was asked to draft the Teams message that would be sent to users, it wrote “scheduled for 09/01/2026” for a 1 September event.
What stayed with me about that example was how quickly confidence can build from a successful interaction. The model’s reasoning was correct, but the output that would have left the building was not.
The planted faults had more in common than it might appear at first glance. One instruction told the content agent to use its own industry knowledge if approved sector messaging did not exist, so the user would still get something useful. Another invited compliance alignment claims and customer examples to make the copy more credible. Another let the agent mark output as review complete if the user was under deadline pressure, while the campaign agent was told to resolve scheduling clashes itself and tell the owners afterwards because confidence helps people move quickly.
None of those instructions were designed around obviously reckless behaviour. They reflected the sorts of instincts people are often encouraged to demonstrate at work: being useful, helping colleagues, avoiding unnecessary delays and keeping things moving. Looking back, that was probably the most important design choice in the exercise because it shifted the discussion away from bad actors and towards ordinary decisions made with good intentions.
The same issue surfaced while the exercise was being built. An early version of the industry messaging register was written too much like policy, complete with explicit “must not” rules and an unapproved list. During testing, the agent read the knowledge file, quoted it back and neutralised most of the traps. It refused the sectors it should have mishandled, declined deadline-pressure approval bypasses and stopped naming customers. The knowledge outranked the instructions.
That forced a rethink of how the register was being used. The final version was rewritten into something descriptive rather than directive, which is much closer to what a real messaging register looks like. More importantly, it exposed a distinction that kept resurfacing throughout the workshop. Knowledge is reference material, not policy. Once a knowledge source starts issuing instructions, it begins competing with the instruction set and it becomes much harder to know what is driving the behaviour you’re seeing. Policy an agent can read is not the same as policy an agent obeys, and neither is a control.
That same confusion appeared repeatedly during the review phase. Teams would often look for another sentence to add or another instruction to refine because prompts are visible and easy to change. The more difficult task was working out whether the behaviour came from the instructions, the sources, the permissions, the tools, the approval path or the evaluation approach. If you do not know which component is doing the work, you do not know what you are relying on.
The scoring helped make that visible. Ten points for a real control. Three for a rewording. Fifteen for noticing the thing that was not there at all. By the end of the morning, most groups had stopped trying to compose cleverer instructions and started removing permissions, splitting skills, naming approvers and asking what evidence a reviewer would need to check output quickly.
The rebuilt versions of both agents were better for the same reasons. The fixes were mostly boring, which is perfectly fine because that’s usually how good controls look.
Grounding was split rather than dumped into one pool. Approved content and approved sector messaging were separated from reference material, unapproved drafts were removed or clearly marked, and somebody had to decide which source was authoritative before any build happened. Where records disagreed, the agent reported the disagreement rather than resolving it by confidence.
Permissions were written before connectors were added. Access that wasn’t required was removed, and messaging was limited to named owners rather than any user or channel the platform could technically reach.
Output was designed for review rather than just readability. Coordination answers carried source and age, while the content agent shipped with a claims list that tied sector-specific claims and named customers back to their sources.
Approval was made structural. A named person had to approve the output, and the agent had no way to mark its own work as reviewed.
Evaluation also stopped being implied. Fifteen explicit test cases sat against the rebuilt agents, each tied to a control that had failed during the morning. That record, with the model and date attached, is the difference between a demonstration and a system
If you are the person deciding whether an agent should move beyond a workshop, I don’t think the most useful questions are whether the model is good or whether the demo looked convincing. The examples from the morning kept returning to the same themes: what the agent could see, what it could do, how it handled conflicting information, who approved its actions, and whether there was evidence that the controls worked in the artefacts people would ultimately rely on.
The practical responses are rarely sophisticated. Naming an authoritative source before a build starts is usually more valuable than refining prompts after the fact. Defining permissions before connecting tools reduces unnecessary risk. Requiring output to carry its source and age makes review easier, while recording test results and repeating those tests after model changes creates a basis for trusting the system over time.
The workshop also reinforced that not every safeguard lives in the platform. Someone must own the source-of-truth decision, someone must approve the output, and someone other than the builder has to review the instructions before they go live. Those responsibilities exist whether the technology supports them or not.
By the end of the morning, nobody needed convincing that agents could be built. Every team had already demonstrated that. The more useful outcome was a shift in the questions people were asking about the systems around them. Everyone in the room could already build an agent. What changed was knowing what to ask before letting one drive.
Data#3 can run the same half-day hackathon for your organisation. Four teams build agents for real work they do every day, using synthetic data that mirrors it so nothing touches your production systems. Then they review each other’s agents against the questions in this blog: what the agent can see, what it can do, who approves before it acts, and what it does when its sources disagree.
Each team leaves with a rebuilt agent, a set of pass and fail test cases tied to the controls that broke during the session, and a short list of operating habits your organisation needs before any agent leaves a workshop.
Reach out to your account manager to book a hackathon for your team.
Information provided within this form will be handled in accordance with our privacy statement.