The Enterprise AlphaGo Moment

After running two FDE hackathons, I have a more precise understanding of what “48 hours” means.

In Lawted’s 48 Theory, 48 hours has never been a delivery promise to the outside world, nor a demand that a team finish an enterprise AI transformation in two days. It is only the first decomposition: enter the company within a deliberately short window, understand a workflow, and find one piece of real evidence worth investing in.

Ideally, that evidence creates an AlphaGo Moment inside the company.

An enterprise AlphaGo Moment is the first time AI produces a specific, verifiable result inside the company’s own work—one strong enough to change the next decision.

AI does not have to defeat a person, and the system does not have to be complicated. It might catch one error in a human record, compress several hours of work into minutes, or link a result back to the original file for the first time.

The size of the result is not the point. The point is whether the company can verify it with its own hands.

Compressed into one line: the value of a demo is evidence, not performance.

1. Map one surface, then break through one point

When we entered the second FDE hackathon, we did not start building from a single sentence spoken by the boss. We first completed two sets of interviews.

The boss described the problem he could see. Managers described checks and accountability. Frontline workers described what actually happened every day. Only by combining those roles could we see the full workflow.

That is the “surface.”

The surface must clarify at least five things: where real inputs come from, which people they pass through, who makes the judgment, who handles exceptions, and where the final result goes.

But workflow mapping alone turns into consulting. The company gets a picture of the future without knowing whether the team can build any of it.

So we also need to break through one point.

The point should not be 20 percent of every module in the grand plan. It should be one narrow, real chain completed end to end.

We chose one kind of real material, one concrete task, and one result that could be checked on site. When the demo returned an OCR result, it also preserved the original image and exact location. It did not cover the company’s entire knowledge base or try to solve every workflow. It completed one crucial judgment loop.

So “one surface plus one point” is not a slogan.

The surface proves that the FDE understands the company. The point proves that the FDE can change it.

A surface without a point becomes a slide deck. A point without a surface becomes an isolated feature.

2. The real shock comes from the evidence chain

During that demo, the AI result disagreed with a human record.

The first reaction in the room was that the AI had made a recognition error. But after reopening the original image through the demo’s source link and locating the exact evidence, everyone confirmed that the AI record was correct and the human spreadsheet was wrong.

What changed the company’s judgment was not a beautifully generated answer or a sophisticated interface.

When the human and the AI disagreed, the system did not ask the company to “trust the model.” It took everyone back to the original evidence.

The result met four conditions:

- It used real business material;

- It was specific enough to judge right or wrong;

- Every conclusion could be traced to the original source;

- After verification, the company wanted to discuss the next step.

That is an enterprise AlphaGo Moment.

AlphaGo was shocking not because it could describe its capabilities, but because it made a move on a board everyone understood—a move humans had not imagined.

Enterprise AI is the same. The shock does not come from a model explaining itself. It comes from an evidence chain the company can independently verify.

We therefore made the standard for an on-site demo very hard: if a result cannot be traced to the original source, it does not count as evidence.

A chatbot that can answer questions is not enough. A prearranged successful demo is not enough. The system must consume real inputs, preserve sources, record human corrections, and make failures visible.

3. Architecture must be decided after entering the site

The second hackathon also overturned many of our technical assumptions.

The materials were not clean Markdown files. They were large collections of PDFs, images, and heavy project files. Upload time, network speed, remote retrieval, and source traceability quickly became more immediate constraints than model capability.

Architecture, we learned, cannot be chosen by personal preference. It must be shaped by the form of the company’s Context.

If the company mainly has Markdown, small files, and low data volume, a Light mode in which individual Agents read directly may be enough.

If the company has large volumes of images, PDFs, and multi-gigabyte project files, keeping files and execution close to the company through hosted or local deployment is more reliable. Otherwise, half of the 48-hour window can disappear into uploads.

The same logic applies to RAG.

When a single business object can be covered by direct files, structured summaries, and deterministic retrieval, there is no reason to build a second index just to appear technically complete. Reconsider RAG only when cross-project similarity search becomes necessary, one object consistently overflows context, or glossaries and summaries still cannot bridge the semantic gap.

Connecting to the company’s existing IM only solves the entry point.

Employees can start tasks from Feishu, DingTalk, or another IM, but the IM is a Gateway, not the company’s brain. Context, files, Skills, permissions, and feedback records still require a clear source of truth and execution environment.

The technical judgment from that hackathon fits in one sentence: absorb the Context first, then let the Context decide the architecture.

4. Count the people at the workflow entrance first

At another manufacturing site, we corrected another assumption.

Faced with paper forms, our initial instinct was to preserve employee habits and add OCR to structure the contents.

That looked reasonable, but further investigation showed that the people actually filling in the forms were not the whole factory. They were roughly 30 workshop supervisors.

If the real entrance consists of only 30 people, a small training session and direct submission through Feishu may be cheaper than building, maintaining, and correcting OCR over the long term.

But if the entrance includes more than 700 factory workers, asking everyone to register for a new tool, learn a new process, and change habits creates a much larger adoption cost. Preserving the paper form and adding an OCR adapter can then be the better design.

An FDE should therefore neither mechanically insist on “never changing user habits” nor demand a new workflow for everyone whenever AI appears.

The correct judgment compares total costs: the cost of changing habits versus the cost of building and maintaining an automation adapter.

That comparison is impossible until the team enters the site and counts the people who truly operate the workflow.

Thirty supervisors and seven hundred workers require entirely different product designs.

5. A hackathon is not a feature-count competition

After several field projects, we no longer judge an FDE hackathon by how many pages, models, or features appear within 48 hours.

The first stage should leave behind five things:

1. A workflow map validated through interviews with multiple roles;

2. A demo narrow enough to finish but complete enough to close the chain;

3. Real inputs and the original evidence behind every result;

4. A record of successes, failures, and human corrections;

5. One clearly defined question for the next stage.

Evaluation cannot look only at accuracy.

We also record the original task time, AI task time, usable-field rate, task completion, human correction items, traceability, and whether failure is explicitly visible.

The test set must include normal, boundary, and exceptional cases.

Normal cases validate the main path. Boundary cases test missing fields, ambiguous inputs, and oversized material. Exceptional cases test conflicting sources, permission violations, prompt injection, and tool failure.

If every test case was preselected to succeed, the demo proves only that the team can perform—not that the system can enter the company.

The most important signal is not “finished.” It is whether the company will continue to open real materials, assign real users, and enter another round of validation.

6. Forty-eight hours is only the first cut

In Lawted’s 48 Theory, 48 hours is only the first cut in an enterprise AI transformation.

In 48 hours, find one surface and one point, then establish the first verifiable piece of value evidence with real material.

In 48 days, put the demo into real use and distill employee acceptance, edits, rejection, and exceptions into enterprise Context, Skills, workflows, permissions, and Evals.

In 48 weeks, let validated Agents take on end-to-end tasks and redraw responsibilities, permissions, and risk between humans and AI, ultimately changing the organization itself.

So 48 hours is not delivery, and it does not necessarily mean a formal project has begun.

It is closer to a high-density joint investigation: the company observes whether the FDE deserves trust, while the FDE judges whether the company’s problem, materials, people, and organization deserve further investment.

The two sides are not looking for a grand blueprint. They are looking for one fact small enough to verify, real enough to matter, and strong enough to move the next step.

A company does not begin its AI transformation when the boss first understands AI or when the company first buys model accounts.

It begins when the company verifies an AI result inside its own work and is willing to act on it.

That is the enterprise AlphaGo Moment.