This week at Allexive we're running a two-hour hackathon to build an agentic project manager. Not a tool we plug in or an automation we configure, but a working version of a role we don't currently have, built by the team that would otherwise be doing that work manually.
I'm writing this up because most people I talk to think hackathons are ideation events. A day to play with new tools, generate ideas, and feel like the team is innovating. That framing is why most hackathons produce energy on the day and nothing the week after.
I don't think that's necessarily a bad thing. I just think it doesn't hit the mark of what Execs are genuinely trying to deliver.
A good AI hackathon is the opposite.
Tight constraints
Real domain expertise in the room
Realistic expectations
A single metric to aim at, and
Something working by the end.
This is how we run ours, using this week's build as the example, because the planning is where most of the value lives rather than the two hours of building.
What an AI-native company actually is
Before the hackathon makes sense, the why behind it has to land. There's a spectrum of how companies relate to AI today, and the language matters because each rung sits on a different operating model.
AI-aware companies talk about AI without changing how they work.
AI-assisted companies use it to help individuals get faster at their existing tasks.
AI-enabled companies build it into specific workflows so the workflow itself runs faster or cheaper.
AI-native is the layer above all of that, where the operating model itself changes shape.
An AI-native company runs on AI, not with AI. The four key principles I think about mostly are:
The business requires closed loops instead of open ones, where every process feeds back and improves itself.
The whole company queryable, where every action produces an artefact agents can learn from.
No human middleware, where the intelligence layer routes information and humans sit at the edge applying judgement.
AI as the operating system, with every workflow, decision, and process flowing through it.
The thing is, AI-native isn't a company that automated its workflow. That's AI-enabled, and at this point it's table stakes. AI-native means every signal that takes place inside the business impacts every other part of the business in some way, which is a much harder bar to clear.
Here's three examples of what that looks like in practice.
A new client commitment in a Tuesday call updates the engagement record, which updates the deal in HubSpot, which updates the SOW, which informs the proposal we draft for the next prospect in the same vertical.
A learning from one delivery feeds the messaging on the website without anyone copying and pasting.
A coaching point dropped in Slack between consultants flows automatically into the brief for the next meeting on that account, and updates steering documents for agents as part of call planning moving forward.
That doesn't get built overnight. It's a compounding knowledge corpus that has to generate compounding intelligence across the business, and that's the bar we're aiming at.
For us specifically, being AI-native is a deliberate operating-model choice rather than a marketing posture. We're under ten people, and we want revenue per FTE that looks more like a software business than an agency, with margins that follow the same logic.
The challenge is that adding headcount is not how we scale. More people means more coordination tax, more meetings, and more complexity, which is the root of every services business hitting a ceiling. Tiny teams supported by AI infrastructure is the bet.
The upside of being small and AI-native is that the business can pivot on a regular cadence. The downside is no project manager, and that's the gap we're solving in this week's hackathon.
What we have to work with
A quick note on the stack and capability we're building on, because being transparent about what exists is step one of any sensible build.
The stack is deliberately simple:
GitHub for code, skills, plugins, and various context files
Google Drive for files
Slack for comms
Fireflies for transcripts
HubSpot for deals
Google Workspace
Teamwork as the project tool
Vercel / GCP / Azure for hosting
A Mac mini sits on overnight when a worker process needs to run while the rest of the team sleeps.
The team has engineers operating at the frontline of Claude Code, Cursor, and Codex, who understand how multi-agent context actually flows, dipping into OpenClaw/Hermes type builds where needed.
We know where the bottlenecks are. The biggest one is that I can't be a full-time project manager in delivery, and also drive the business in strategy, sales, marketing, partnerships etc. Leaving engineers to run client engagements end-to-end isn't fair on them either, and we know the blowback from that approach. So we need an orchestration layer that ensures responses to clients are efficient, engagement management is reactive, information flows freely between systems, reporting up and down works, and cross-client learning is visible enough that what we ship for one client improves what we ship for the next.
In a bigger team, that orchestration layer is a PM. In ours, it has to be AI supporting the human, and that's the brief.
How I planned this hackathon
I spent 25 minutes this morning at 3 a.m., feeding Paddy a bottle, Claude in hand, back and forth with Claude's AskUserQuestions tools in Claude Code to sharpen the brief, until I had something to put in front of the team, and turned that into an artefact for pretty visuals.
The structure of the planning conversation, in order:
**What's the problem we're not solving today?**Named it specifically. Not "we don't have a PM" in the abstract, but "we are reactive, not proactive. Files get created, but nothing notifies the human to do something with them. Signals enter the business through Fireflies, Gmail, Slack, HubSpot, and Teamwork, but nobody is watching them on our behalf".
Where are the bottlenecks? We are the orchestrators, all of us, and we work from partial signal sets, because three transcripts get summarised but the SOW from last week, the email negotiation, the coaching given in Slack, and the previous engagement's lessons are all missing when someone sits down to prep the next call, relying on human memory recall.
**What are the jobs to be done?**Pre-meeting prep, post-meeting follow-through, comms triage, and cross-engagement awareness, with the goal of picking the smallest slice that proves the loop closes.
**What's the architecture?**Hub-and-spoke per engagement rather than monolith files, with a master engagement file that routes to tightly scoped spoke files, because tighter context outperforms one bloated context file and this is itself a context-engineering principle worth standardising on. We have this architecture in-place, but managing context architecture is a constant art and science of pruning and maintenance.
What types of context files do we need? Steering documents for how we behave, knowledge documents for what we know, state documents for what's true now, trigger documents for what just happened, and working documents for what to do this minute, because that taxonomy becomes our new internal standard and mixing the categories is what causes prompt bloat and steering drift.
**What's a single metric?**Engagement state freshness, which is the median age of every engagement record across active clients, with green under six hours, amber up to two days, and red beyond that, because if freshness drifts then the loop is broken.
**What are the risks?**The team builds a demo not a system, we over-build the capabilities before the brain is shaped, we stub the cadence layer and never ship it for real, and trust collapses on the first wrong action because we let an agent send something without human approval, with each risk getting a mitigation written down before the hackathon starts.
That's the planning, and it maps to four layers I now think about for any AI build: context, connections, capabilities, and cadence.
Context is what the system knows.
Connections are the data sources it can reach.
Capabilities are the skills and agents that act on it.
Cadence is what runs proactively while the laptop is closed.
To be super clear, we have decent context and connections, our capabilities are getting strong, but our cadence layer is the gap and that's what this hackathon ships.
Seeding the team in the week before
Your team can't walk in cold. The week before the hackathon, three things happened deliberately, because the two hours on Friday only works if the week before has done its job.
The first thing was pre-reading. I sent the team a piece by Diana Hu (YC partner) on AI-native companies, not to brief them on a framework but to externalise the urgency, because this isn't a Mike-pitched internal initiative but the position partners at YC are taking publicly, which changes the energy in the room.
The second thing was idea seeding. I dropped conversations throughout the past month about how context carries between agents and files, comments in Slack about proactive context management, and small framings inside normal conversations so the team arrives Friday with the question already half-formed in their heads.
The third thing was parallel pre-work, where two of the team started builds that fed the hackathon directly. The team rebuilt internal infrastructure on the Mac Mini that had been failing on us too regularly to trust, while we also rebuilt our SOW generator skill over the past couple of months, which I'd hacked together in January. The skill had been working alright, though it isn't technically sound, and putting it through a software-engineering rebuild has levelled it up, especially with newer models and platform capabilities.
Both pieces of pre-work make Friday's hackathon easier because the foundations are firmer. By the time Friday arrives, the team has context, the foundations are stronger, and the brief is sharp.
The basics most hackathons miss
Five things separate a hackathon that compounds from one that evaporates, and getting these wrong is why most hackathons fail to ship anything that survives Monday.
Domain expertise plus AI expertise in the room. The domain person knows the problem deeply enough to call out when the team is building the wrong thing. The engineering lead knows what's buildable in two hours and what's a six-week project pretending to be a demo. Having both in the same room is the multiplier.
Focus on one problem rather than a list of ideas to vote on. Five teams half-building five things produces five demos and zero compounding, whereas the whole team working the same problem from different angles produces something the firm can extend next month.
A starting point that isn't a blank page. People need a brief, a constraint, and a hypothesis to react to. For this hackathon, the brief is one sentence: build the slice of an agentic PM that ingests a real client transcript, updates the engagement record, then surfaces what changed for human review, with no human triggering the loop, autonomously, and impacting other parts of our business. We won't necessarily solve for this, but the upfront thinking outlines the vision for this work, and we can build on this over the coming hackathons.
A single metric the build is aiming at. Critical.
Permission to take the time. The team won't show up properly while feeling stressed about being out of inboxes for two hours. The leader has to make the time genuinely protected: calendars cleared, no half-presence.
The challenge is that the problem also has to be relevant to the people in the room. We could have run this hackathon on improving pre-sales, but the majority of the team works in delivery, so we're solving a delivery problem first, and the pipelines and capabilities developed here are transposable upstream and downstream later. The rule for me is to pick the room's pain rather than the leader's pain.
Freedom inside guardrails
The reframe most people need on hackathons is: not free experimentation, but bounded experimentation, where the guardrails are the gift rather than the constraint.
The problem is fixed, and the solution is wide open.
The metric is fixed, while how the team moves it is open.
The time is fixed at two hours, rather than "until we're done".
The output format is fixed: ship something working, however small.
Inside those four boundaries, the team has full creative freedom, which is the design. Without the boundaries, freedom becomes drift, which produces slides instead of working systems.
Build, don't just present ideas
The trap is spending two hours generating ideas, ending with a deck of options, and calling it a hackathon. That's a workshop rather than a hackathon, and while it's useful, it doesn't compound.
A hackathon ends with something built, even if it's small or ugly or only works on one client's data. The act of building forces decisions that pure idea generation hides:
which idea survives contact with real inputs, what's missing from the steering documents
where the agent breaks, and
what humans still need to do versus where they can hand off.
Building produces evidence while pure idea generation produces opinions, and that's where the compounding lives. There's no barrier to building these days either, vibe code away!
If this week's hackathon ships a working transcript ingester for our agentic PM, next month's hackathon extends it, hardens it, or wires the next signal source in. One-off hackathons that produce decks don't compound, but hackathons that ship working slices do, and the firm's operating model gets rebuilt one slice at a time.
The harder truth is what AI-native looks like in practice. We're not turning a context file into multiple files, because that's table stakes sitting at the bottom of the maturity ladder.
What we're doing is closing learning loops: context carries from a Tuesday morning call through to a Tuesday afternoon email and meeting in a fortnight time. Signals in delivery surface in sales. Information flows between systems automatically. The right thing reaches a human at the right moment, so they apply judgement rather than just route information.
The shape we're aiming at is a data intelligence layer at the centre of the business, with humans steering at the edge. Humans don't get taken out of the loop; they get freed up to apply judgement, which is the part of the loop humans do best.
How we structure ours
Not a step-by-step playbook, just the design choices that are important and the trade-offs we've already made.
Two hours, no more. Long enough to ship something. Short enough that nobody cancels.
70 minutes design and 50 minutes build. Most teams flip this and regret it. The thinking is the IP. The build is the forcing function that exposes whether the thinking holds up.
Pre-reads sent a day out. They contextualise the why before the room is in motion.
Start big, then zoom down. Open with the operating-model frame so the team understands we're rebuilding how the firm runs, not adding a feature. Then narrow ruthlessly to one slice.
Domain expertise plus AI expertise on the brief, where the domain person says what's worth building while the engineering lead says what's buildable in two hours.
Parallel build tracks, not consensus. Split into tracks for schema and steering docs, ingestion, and surfacing changes back to humans. The integrations at the end expose where the design has holes.
Ship something in the room, and demo it at the end. Whatever's built, however rough, runs end-to-end on real data.
Nothing auto-sends in v0.1, with drafts only, human approval, and audit logs, because trust is earned action by action.
Risk and mitigation done before the hackathon rather than after, asking where this could fall over, what the gap is, what the metric is, and how the team knows it worked next week rather than just at the demo.
The next hackathon is booked before this one starts, otherwise momentum dies. v0.2 is already in the calendar.
Why hackathons rebuild the firm
A hackathon isn't a perk or a culture activity. It's the way we rebuild how the firm operates.
Every company will need to rebuild its processes to be AI-native, and there are two ways to do it.
Hire a consultancy to redesign everything top-down.
Or run a regular hackathon cadence and rebuild the work bottom-up with the people who actually do it.
We do the first one for clients. For ourselves, we run hackathons.
The agentic PM we're building this week isn't the point. The point is that by 5pm, a piece of how Allexive operates will work differently than it did this morning, and the team that built it owns it, extends it, and improves it next time, which is the only way I've found to make AI-native real instead of a slogan.
Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.
Subscribe to The AI Corner
