SIGNEDRECORD

TechIreland National AI Challenge 2026 · Enterprise Software

CoWork

The org chart for AI agents.

Steer once  ·  Scale everywhere  ·  Sign the record

Live demonstration: cowork-demo.pages.dev

01

Slide 01 · Title 0:00 – 0:10

Do not read the slide. Stand still. Let the wordmark sit for two seconds before you speak.

"We're CoWork. In seven minutes I want to convince you that the thing standing between enterprises and AI agents is not intelligence. It's an org chart."

The market today

Everyone is shipping the worker. Nobody is shipping the workplace.

Coding assistants

Copilot, Cursor. One developer on one project, very fast.

Autonomous agents

Work on their own, but inside one project at a time.

Cloud workspaces

Supply the computers agents run on. Not the approvals.

Workflow suites

ServiceNow, Atlassian. Built for people clicking buttons.

Every one of them gives you something that does the work. None of them decides who is allowed to act, who approved it, and what is on the record once that work crosses from one team into another.

Category judgements from public positioning, not audited comparisons. Capabilities in this market change quickly. The point is the pattern, not the vendor names.

02

Slide 02 · The market today 0:10 – 0:35

This slide sets the frame for everything after it. Say the headline, pause, then sweep a hand across the four boxes. Do not read them.

"There's a new AI tool for building software every week. Coding assistants. Autonomous agents. Cloud workspaces to run them on. Every one of them ships the worker: something that can do the job."

"Not one of them ships the workplace. Who is allowed to act. Who approved it. What is on the record. That gap is why we're here."

What changed

Enterprises just hired a thousand workers with no job title, no manager, and no signature on file.

Coding agents crossed the line where they can genuinely do the work. So the constraint moved. It is no longer whether the machine can write the change. It is whether anyone in the building is allowed to let it.

$2.59T Forecast worldwide AI spending, 2026 · +47% YoY

Every euro of it lands in an organisation that has no procedure for what it just bought.

Gartner, 19 May 2026. A forecast, not observed spend — cited here for market motion and timing only, not as evidence for anything about CoWork.

03

Slide 03 · What changed 0:35 – 1:00

"And those workers are genuinely good now. So every large company is about to point hundreds of them at its own systems, and not one of those companies has an org chart for them. No job titles. No manager. Nobody's signature on file."

Beat. Then the caveat, said out loud — it buys you credibility for every number that follows.

"That number on the right is a Gartner forecast, not measured spend. I'll flag every number I use that way."

The problem

Agent projects are not failing on intelligence. They are failing on permission.

CostEscalating, unbudgeted
ValueUnclear business case
RiskInadequate controls
40%+ Of agentic AI projects
cancelled by end of 2027

Those are the three causes Gartner names. Not one of them is a model problem. All three live in the organisation: who pays, who benefits, who is accountable.

Gartner, 25 June 2025. A forecast, not an observed cancellation rate. It establishes that the gap is real and unmet. It is not evidence that our answer to it is accepted — we keep those two claims apart.

04

Slide 04 · The problem 1:00 – 1:35

This is the spine of the whole pitch. Slow down. Land the three causes one at a time.

"Gartner forecasts that more than forty percent of agentic AI projects get cancelled by 2027. The interesting part isn't the number, it's the reasons they give. Cost. Unclear value. Inadequate risk controls. Read that list again — not one of them is a model problem. Every one of them is an organisational problem. Better models will not fix a single line of that list."

"And again: that's a forecast, not an observed rate. It tells us the gap is real. It does not tell us we close it."

What that looks like today

One security flaw. Sixty backlogs. Six months.

Day 0

A security flaw is found in a login library that sixty services share.

Day 1

An automated find-and-replace is tried. It fails on the first service built its own way — after five years, no two look alike.

Week 2

No central team knows sixty systems well enough to fix them all. The fix goes out to sixty teams as a ticket.

Month 6

The flaw is still open in fifteen of them, queued behind fifteen other priorities that each have an owner.

~39% Of IT team time goes to building and testing the connections between systems

The work is not writing the fix. The work is everything around the fix.

MuleSoft 10th Annual Connectivity Benchmark, 2025. A vendor survey of IT leaders — MuleSoft sells integration middleware, so the instrument is not disinterested. Used as a directional proxy for the coordination tax. We have no cost model and do not imply one.

05

Slide 05 · What that looks like 1:35 – 2:00

"Here's what an organisational problem looks like in practice. A security flaw is found in a login library that sixty services share. Someone tries an automated find-and-replace, and it fails on the first service that was built its own way. So it becomes sixty tickets in sixty backlogs, and six months later it's still open in fifteen of them."

"The work was never writing the fix. The work is everything around the fix."

Why nobody has fixed it

AI is eating SaaS. But SaaS was never the software.

Enterprise SaaS was valuable because it encoded organisational problem-solving. Roles. Approvals. Compliance. Coordination. The software was only the delivery vehicle for those.

Agents eat the delivery vehicle. They do not eat the organisation. That layer now has nothing to run on. It is the thing we are building.

The one sentence to take out of this room: agents need a workplace, not just a workbench.

06

Slide 06 · Why nobody has fixed it 2:00 – 2:30

This is the slide the whole pitch exists for. Ask the question first, then stop moving. Let the room sit in silence for a full second after “the organisation.”

"So why has nobody fixed that?"

"Everyone says AI is eating SaaS, and they mean the code. I think that's the wrong read. Enterprise SaaS was never valuable because it was software. It was valuable because it encoded organisational problem-solving — roles, approvals, compliance, coordination. The software was just how you delivered those."

"Agents eat the delivery vehicle. They don't eat the organisation. So that layer is now sitting there with nothing to run on. Agents need a workplace, not just a workbench. CoWork is the workplace."

CoWork

One human authorises a fleet of agents, once — and can prove what they authorised.

The unit of work moves from one team’s code change to one organisation-wide change with a signed record.

Steps 1, 2 and 3 are where AI does the work. Step 4 is deliberately not AI — see slide 9.

07

Slide 07 · The loop 2:30 – 2:50

"Four steps. Send one change to every service that needs it, at once. Every agent works in isolation and has to pass that service's own checks. Where an agent hits something only a person may decide, it stops and asks. And everything is signed with that person's name."

"Let me show you what that looks like."

Live demonstration

Sixty services. One security upgrade. One human decision.

Sent out

One security upgrade, to every service that needs it, at once.

Stopped

Fifteen stop, each at a choice an agent is not allowed to make.

Decided

A person opens one of them, billing, and makes that choice once.

Spread

The decision reaches the other fourteen. Each re-checks itself before turning green.

Signed

One receipt with the approver’s name. Change one character and it refuses to verify.

45Finished on their own
15Stopped and asked
1Human decision clears all fifteen

The model is capable. It is deliberately not authorised.

Running live at cowork-demo.pages.dev. If it cannot run, backup stills for the cascade and the receipt are in Appendix C and D.

08

Slide 08 · Live demonstration 2:50 – 5:00

Show this slide for about ten seconds as the map, then switch to the live demo. Everything below is said over the demo, not over the slide.

"This is one security upgrade, sent to sixty services at once."

Switch to the demo. Leave the full grid on screen.

"Forty-five finished on their own. Fifteen stopped. And the fifteen that stopped are the whole product, because an agent that guesses its way through those is exactly what your risk team is afraid of."

Click worker 18, billing-core. Wait for the drawer to open.

"So we open one. Not fifteen, one. Billing. The old account format doesn't map cleanly onto the new one, and choosing that mapping is a business decision. The agent could have written the fix. It wasn't allowed to choose it."

Click Inject Shim Diff, then Propagate. The drawer closes itself. Step back and let the grid turn green before you speak.

"Now watch one decision reach the other fourteen. It isn't copy-paste. It only applies where the same problem appears, and each service re-runs its own checks before it turns green. Anything that fails stays stopped. Sixty of sixty. One human decision."

Click Consent Gate Ready in the bar at the bottom. Scroll inside the card to the tamper button before you start talking.

"And this is what the risk team gets. Every service, every change, the approver's name. And zero attempts to send anything outside, under a deny-everything policy. That zero is a signed count anyone can re-check, not a promise."

Do NOT say “mathematical proof that nothing left the network.” A technical judge will ask how you prove a negative. Then click Simulate Tampering.

"Change one character. Refused. Anything can say valid. The value is that it can say invalid."

Switch back to the deck.

Build with AI

This problem is made of AI, and only AI can answer it.

It exists
because of AI

Organisation-wide change made by agents is a 2026 problem. In 2023 nobody needed to approve what sixty agents did overnight, because there were not sixty agents.

It is solved
by AI

Sixty systems built differently over years defeat any script — that is why the find-and-replace fails. Each one needs an understanding of how that system was built. That understanding is the AI part, and nothing else supplies it.

It is bounded
by not-AI

The approvals, the identities and the signed record are deliberately not AI. An audit that depends on a model being in a good mood is not an audit.

We use AI where judgement is needed and refuse it where proof is needed.

The same discipline ran the build: agents wrote most of this system, under a contract-first plan, with every claim in our own documentation carrying the qualifier it can support.

09

Slide 09 · Build with AI 5:00 – 5:25

Bridge straight from the demo — you have just shown both halves. “Build with AI” is a scored criterion, and most teams answer it by naming the model they called. Answer it structurally instead.

"What you just watched is two different kinds of machine. The agents did the understanding: sixty systems built differently over years, which no script can handle. That problem only exists because of AI, and only AI solves it."

"And the approval, the names and the receipt are deliberately not AI. An audit that depends on a model being in a good mood is not an audit. We use AI where judgement is needed, and refuse it where proof is needed."

Who buys it, and what they pay

Sold to the two people who have to say yes.

Holds the mandate

Head of Platform

Can order a change across sixty services. Cannot vouch for what happens inside each one.

Holds the veto

Head of Risk & Compliance

Can approve the change. Today has nothing to approve it with.

What makes them buy: a security fix with a deadline, an external audit, DORA, or the EU AI Act.

Per governed service, per month

Team

€40

Enterprise

€120

Regulated

Custom

Example

200 services on Enterprise is €288k a year.

Land

One security fix that has a deadline and an owner.

Expand

Every organisation-wide change after it.

Buyer roles are composites from a sector every member of this team has delivered into. We did not run interviews for this build. Pricing is a proposed structure, not a tested one, with no customers behind it.

10

Slide 10 · Who buys it 5:25 – 6:00

The business slide. Two sentences on who, two on price. Point at each buyer as you name them.

"So who pays? Two people have to say yes to a change like the one you just watched. The head of platform, who can order it but can't vouch for it. And the head of risk, who can approve it but has nothing to approve with today. CoWork gives each of them the thing they're missing."

"We charge per service we govern, per month, because that's the unit a platform budget is already written in. Two hundred services is about two hundred and ninety thousand euro a year. We land on one security fix with a deadline, and expand to every organisation-wide change after it."

If pressed on the numbers: it is a proposed structure with no customers behind it, and the slide says so. Defend the unit, not the price.

Market · built from the bottom up

€5.4BTotal addressable — organisations worldwide running 100+ production services
€1.1BServiceable — regulated sectors first: financial services, health, public sector
€5MObtainable — Ireland and UK regulated beachhead, five-year horizon
Assumption 1

~25,000 organisations worldwide run 100+ production services. Our estimate, not a published figure.

Assumption 2

150 services average × €120/service/month = €216k annual contract value.

Assumption 3

Regulated sectors are ~20% of that population and are where the compliance trigger already exists.

We would rather show you arithmetic you can argue with than a market-report number you cannot.

Every input above is an assumption we are stating, not a sourced figure. Change any one of them and the total moves — which is the point of showing them. No top-down market-sizing report underwrites this slide.

11

Slide 11 · Market 6:00 – 6:10 — optional, cut this first if you are running long

"On sizing — I could quote you a five-billion-dollar market report. Instead here's arithmetic you can argue with. Roughly twenty-five thousand organisations worldwide run a hundred or more services. At a hundred and fifty services average, that's about two hundred and sixteen thousand a year each. Regulated sectors are about a fifth of that and they're where the compliance trigger already exists."

"Every one of those inputs is our assumption, and they're on the slide so you can take one apart."

Team

We have each shipped production software inside the sector we are selling into.

Ersi NiLead
Sreekanth
Palagiri
Team
Kaushal
Bhavsar
Team
Mayuri
Bhosale
Team
Sudhanshu
Akarshe
Team
Shared ground

Every one of us has built and delivered production systems in banking, financial services and insurance. The regulatory environment this product assumes is the one we have worked inside.

Also behind us

Health and medical, automotive, and large-scale consumer internet.

What that buys

We are not guessing why a security fix sits in a backlog for six months, or what a change-approval board asks for before it signs. We have been on both sides of that table.

And the limit, stated the same way as every other claim here: having worked in the sector is not the same as having validated this product with its buyers. It is the question we close on.

12

Slide 12 · Team 6:10 – 6:30

Say the names once, then get straight to the credential. Do not walk the panel through five biographies.

"Five of us. The thing worth knowing is that every one of us has shipped production software in banking, financial services and insurance. That is not a coincidence with the pitch. It is why we picked this problem. Between us we have also worked in health and medical, automotive, and consumer internet at scale."

"So we are not guessing why a security fix sits in a backlog for six months, or what a change-approval board wants before it signs. We have been on both sides of that table."

Then close the loop on your own honesty rule. This is what makes the credential land rather than sound like a boast.

"And the limit, same as everything else I have shown you: having worked in the sector is not the same as having validated this with the people who would buy it. That's the question I want to close on."

The ask

Enterprises will not deploy agents they cannot supervise.

CoWork is how one person says yes to sixty at once — and can still prove, afterwards, exactly what they said yes to.

What we want from this room

We could not reach the buyer before today. So the single most useful thing we can leave with is an answer to one question: would you approve a real change across your organisation on the receipt you just saw?

CoWork  ·  cowork-demo.pages.dev  ·  TechIreland National AI Challenge 2026

13

Slide 13 · Close 6:30 – 6:50 — leaves ten seconds of slack

Do not thank them and trail off. End on the question, then stop talking. Silence is fine — it hands the room to Q&A on your terms.

"Enterprises will not deploy agents they cannot supervise. CoWork is how one person says yes to sixty at once and can still prove afterwards exactly what they said yes to."

"One ask. We couldn't get in front of a real buyer before today, so the most valuable thing we can walk out with is your answer to one question: would you approve a real change across your organisation on the receipt you just saw?"

Appendix A · Q&A

The eight questions you will be asked

"Isn't this
a for-loop?"

No. What propagates is a match condition, not a patch, and each recipient re-earns its green by running its own tests in its own sandbox. A for-loop cannot fail safely; this stays blocked when it fails.

"Why not
Copilot?"

Copilot and Cursor are one developer in one repository. Zero cross-repo authority, zero approval gate, zero record. They are the worker; we are the workplace.

"What if the
agent is wrong?"

Then its tests fail and its tile stays amber. Being wrong is a modelled state, not an exception. The system is designed around the assumption that some agents will be wrong.

"GitHub will
just build this."

They own an org layer shaped for humans clicking a UI, and that shape is their revenue model. Reshaping it for agents cannibalises seats. That is a strategy problem, not a technical one.

"Is the demo
real?"

The engine, the blast-radius fence and the signing path are real code. Cloud mounts, inference and Slack are modelled deterministically. Appendix E sets out exactly which is which.

Answer the hostile version of every question before the friendly one. A panel that spots an unaddressed objection discounts everything else you said.

14

Appendix A · Q&A defence

Three more, kept off the slide because they are rarer:

"Who is liable if it breaks production?" — The named approver in the receipt, which is deliberate. The receipt exists so that liability has somewhere to land instead of evaporating into "the AI did it."

"Why would a CISO ever allow this?" — They already allow it, badly. Engineers are running agents on production code today with no gate and no record. We are not introducing the risk, we are introducing the control. That reframe matters: the counterfactual is not "no agents", it is "ungoverned agents."

"What is your unfair advantage?" — Honest answer: none yet, we are three weeks old. The structural answer: consent, identity and signature are awkward to bolt on afterwards, so whoever builds the governance substrate first has a real head start over anyone who built the worker first.

Appendix B · The governance layer

The four roles that make it governable

Who may act

Identity. Task-scoped credentials. The agent can reach exactly what the task needs and nothing else — not the database, not production keys, not customer tables.

Who approved

Consent. A policy gate at the boundary. Nothing merges without a named human signing off, and the policy says which changes need which human.

What happened

Audit. A signed chain of reasoning, diffs and test receipts. Not a log you hope is complete — a record you can replay and re-derive.

What it looks like

Verification. A human sees the change rendered, not just a diff. You cannot approve what you cannot look at.

These four are the product. Compute and storage underneath them are commodity. Consent, identity and signature are the part that is awkward to bolt on afterwards — which is where the defensibility sits.

Roles, before and after: the human contribution moves from doing to steering and approving. New machine roles appear to carry approval, compliance and verification.

15

Appendix B · The governance layer

Use if a judge asks what the product actually consists of, underneath the demo.

Read the four left-hand labels as questions, not features. They are the four questions a compliance officer asks.

"Four questions decide whether an agent change is shippable. Who may act — the agent gets credentials scoped to the task, so it physically cannot reach the database or production keys. Who approved — a policy gate with a named human at the boundary. What happened — a signed record you can replay, not a log you hope is complete. And what does it look like — because you can't approve what you can't see."

"Compute and storage under that are commodity. This layer is the part nobody can bolt on afterwards."

Appendix C · Propagating safely

Demo · Propagate, safely

The rule carries a match condition, not a patch.

It is not a copy-paste. The adapter is bound to a failure signature and a directory-bounded path pattern. It applies only where that exact signature appears, and nowhere else.

Every recipient re-earns its own green. Each of the fourteen runs its own test suite in its own sandbox before its tile changes colour. Passing is measured, not inherited.

Failure does not travel. Anything that fails stays blocked and isolates itself. Bad code cannot ride the cascade out to the fleet.

60 / 60Resolved
1Human decision
14Propagated · each independently verified
0Escapes past the blast-radius fence

Blast radius is enforced by directory-bounded POSIX glob semantics at the engine level and re-counted from the emitted records at sign-off. The fence is checked twice, by two different mechanisms.

16

Appendix C · Propagating safely

Backup still for the cascade, and the slide to go to if a judge asks “isn’t that just copy-paste?”

The drawer now closes itself on propagate and scrolls the matrix into view, so just click and step back. The sweep to green runs for about a second and a half — let them watch it before you speak.

The silent objection in the room right now is "so it's a for-loop." Answer it while the cascade is running, not in Q&A.

"Now watch what one decision does. And I want to be precise about this, because it looks like copy-paste and it isn't. What propagates is a rule with a match condition, not a patch. It fires only where that exact failure signature appears, inside a bounded set of paths."

"And every one of those fourteen runs its own test suite in its own sandbox before it turns green. It earns the green, it doesn't inherit it. Anything that fails stays blocked. Bad code cannot ride the cascade."

"Sixty of sixty. One human decision. That's the leverage."

Appendix D · The receipt

Demo · The receipt

Measured from the emitted records. Not asserted.

REPOSITORIES60
WORKERS60 spawned · 60 resolved
PULL REQUESTS60 pre-verified
EGRESS CALLS0  under a deny-all policy
APPROVERhuman:platform-lead@corp.internal
SIGNATUREEd25519 over an RFC 8785 canonical Merkle head

Then we flip a single byte of the payload and re-verify.

✕  Attestation refused

Signature discrepancy over the canonical JSON.

The value is not that it can say valid. It is that it can say invalid.

Note the honest phrasing of the egress line: the policy was deny-all and the receipt counts the attempts. We are not claiming a proof that nothing left the network — we are claiming a signed count that anyone can re-derive.

17

Appendix D · The receipt

Backup still for the receipt, and the slide to go to if a judge asks how the signature works.

Open the consent gate. Scroll to the tamper button before you start talking so you are not hunting for it mid-sentence.

"Now the other side of the building. The compliance lead gets this. Sixty repositories, sixty pre-verified pull requests, zero egress calls under a deny-all policy, and a named human's identity bound into the signature."

Say this exactly. Do NOT say "mathematical proof nothing left the network" — a technical judge will ask how you prove a negative and you'll lose the room.

"And be careful how you read that zero. We are not claiming proof that nothing left the network. We're claiming the policy was deny-all, the receipt counts the attempts, the count is zero, and it's signed — so anyone can re-derive it."

Click Simulate Tampering.

"Flip one byte. Refused. And that's the point — the value isn't that it can say valid. Anything can say valid. The value is that it can say invalid."

Appendix E · What we built, and what we did not

What we built, and what we did not

Built & verified

A deterministic coordination engine. Directory-bounded blast-radius enforcement. The fifteen-worker cascade, at contract and engine level. The signing and verification path — tamper detection is real, not staged.

Represented deterministically

Cloud sandbox mounts, live inference, and Slack sign-off are modelled, not live. The engine replays identically by design, so the demonstration cannot go down — and neither can the audit.

Not claimed

Live model accuracy. Empirical generality across live external repositories. And above all: that enterprises will accept this receipt.

That last one is the kill assumption. If platform and security leads refuse autonomous cross-boundary agents even with a signed, replayable receipt, the thesis fails no matter how good the demo is. We could not test it before this room.

Stating this is not a hedge. A system whose whole proposition is auditability has to be audited about itself first.

18

Appendix E · What we built, and what we did not

Go here the moment a judge asks “is the demo real?” or “what have you actually built?” Answer from the slide, without apologising.

Most teams hide this slide. Put it on stage deliberately and make eye contact. It reframes every claim you already made as trustworthy. Do not apologise while saying it.

"Let me be exact about what's real. The coordination engine, the blast-radius fence and the signing path are built and verified — the tamper detection you just saw is real code, not a staged animation. The cloud mounts, live inference and Slack sign-off are modelled deterministically, which is also why the demo can't go down."

"And what we are not claiming: live model accuracy, generality across real external repos, and most importantly, that enterprises will actually accept this receipt. That's the assumption that kills us if it's wrong, and we couldn't test it before walking into this room. A system that sells auditability should be audited about itself first."

Appendix F · Evidence

Three numbers and the exact limit of each

40%+ cancelled
by 2027

Gartner, 25 June 2025. A forecast, not an observed rate. Supports: the failure mode sits in the organisational layer, since the named causes are cost, value and risk controls rather than capability. Does not support: that governance is sufficient to rescue those projects, or that a signed receipt is what buyers accept.

~39% of IT
team time

MuleSoft Connectivity Benchmark, 2025. A vendor survey by a company that sells integration middleware — the instrument is not disinterested. Supports: the coordination tax is large and persistent. Does not support: any euro figure for coordination. We have no cost model.

$2.59T AI spend
forecast 2026

Gartner, 19 May 2026. A forecast. Supports: market motion and timing. Does not support: anything about CoWork. It is context, and no claim we make rests on it.

All three establish that the problem is real. None is evidence that our answer to it is accepted. We do not run those two claims together, on a slide or on stage.

House rule: if a qualifier feels too heavy for a slide, the number is doing more work than it can support — cut the number, not the qualifier.

19

Appendix F · Evidence

If a judge challenges a number, do not defend it. Turn to this slide and read them your own caveat before they finish the question. It converts an attack into a credit.

Appendix G · Scenarios

Where it goes after the first CVE

Scenario 2

Breaking contract migration

A payment-settlement contract moves from synchronous REST to event-driven payloads, across four bounded contexts in four languages. No single developer can run all four locally, so teams push to shared staging and break it for fifty other engineers.

With CoWork: all four repositories mount as one dispatchable unit, the end-to-end flow is verified against an ephemeral database, and four linked pre-verified pull requests come out the other side.

Scenario 3

Adjudicating two competing agent plans

Two AI-generated migration plans for the same upgrade — one internal, one from a vendor. Both claim CI is green. There is currently no way to evaluate, compare or reproduce an AI-generated strategy.

With CoWork: because every run is a signed replayable trace, both candidates replay in the same sandbox against the same baseline. You see which one actually passes, not which one claims to.

You cannot trust what you cannot replay.

Scenario 3's trace-comparison view is designed, not built. It is shown because it answers the open problem the AI community keeps naming; presenting it as shipped would be worse than omitting it.

20

Appendix G · Scenarios

Use scenario 3 only if a judge asks "what's next" or "how big can this get". It is the strongest expansion story you have — it makes CoWork the adjudication layer, not just the execution layer — but it is not built, and saying so is mandatory.

01 / 20
← → navigate  ·  N notes  ·  P print to PDF