Enterprise AI Pilotsby The Goodstack Company Propose a pilot

Turn an AI pilot into a working business system

We connect AI to the systems your team already uses: the CRM, the ERP, the document store, the portal. We start with one workflow and a small group of your people, with scoped access to real data and a person reviewing every exception. You see it running before anyone commits to production.

Propose an AI pilotRead the pilot acceptance checklist

The pilot proved the model. The workflow is still unproven.

These are the blockers people describe in public when an AI pilot stalls.

Ref.Failure modeWhat happens
F-01

The demo ran on sample data, not yours

A model can answer questions about an exported spreadsheet. Scoped, permission-aware access to the live systems your team uses every day is a different project.

F-02

No one agreed what passing looked like

Without a written baseline and acceptance criteria, a pilot runs until interest runs out, with no moment where a sponsor can call the result a pass or a fail.

F-03

Access became the real blocker

IT and security have to approve what a system can read and write before anything ships. Starting that review after the pilot is built stalls it in the queue.

F-04

The exceptions had nowhere to go

Every workflow produces a case the rules did not anticipate. With no reviewer and no log for it, the first wrong action is the last time anyone trusts the system.

Note We are not claiming most AI pilots fail for these reasons, and we have not measured how common each one is. They are the problems the checklist below is written to catch early. The failure statistics quoted at executives are a separate matter, and we traced the main ones back to what was actually measured.

One workflow, scoped access, a person handling exceptions

An AI pilot is a defined set of actions, taken with permission, logged, and reviewed by the people who own the workflow. If you are weighing enterprise AI agents across departments, or an AI phone agent connected to your CRM, those guides list what to decide first.

How a pilot reads data, acts and is reviewed Source data passes a permission boundary signed off by the IT or data partner. The workflow's output goes to the evaluation harness. Output at or above the agreed threshold becomes an approved action in the CRM, ERP, documents or portal. Output below it goes to a reviewer, whose corrections feed back in. Every step is written to the audit trail and cost model. Source data System of recordRead only what theworkflow needs Permission boundary IT or data partner signs off One workflow Defined actions,taken withpermission Evaluation harness Checks outputagainst thebaseline At or above threshold Action systems CRM, ERP, documentsor portal. An approvedaction lands here. Below threshold: flagged Reviewers A person handles theexception and feedsthe correction back. Corrections Audit trail and cost model Every action is logged. Operating cost is tracked against the baseline from the first week. How a pilot reads data, acts and is reviewed. Source data passes a permission boundary, the workflow's output is checked by the evaluation harness, passing output lands in the action systems, flagged output goes to a reviewer, and every step is written to the audit trail. Source data System of record,scoped read Permission boundary IT or data partner signs off One workflow Defined actions,taken with permission Evaluation harness Checks output againstthe baseline At or abovethreshold Below:flagged Action systems CRM, ERP,documents orportal Reviewers A person handlesthe exception Corrections Audit trail and cost model Every action is logged. Operating cost is tracked against the baseline from the first week.
Fig. 1 Marked in yellow: the permission boundary, which your IT or data partner signs off, and the reviewer who handles the exceptions.
Who uses itWhat they do

Business-unit sponsor

Owns the outcome and makes the production decision at the end.

Process owner

Knows the workflow today and defines a correct result.

The small user group

Uses the pilot against real work and tells us where it is wrong.

IT or data partner

Grants access, sets the permission boundary and signs off on it.

Reviewers

Handle the exceptions the system flags and feed corrections back in.

What it connects toIts part

Source data

The authoritative system of record. Access is scoped to what the workflow needs.

Action systems

The CRM, ERP, documents or portal where an approved action lands.

Evaluation harness

Checks output against the baseline and flags anything below the agreed threshold.

Audit trail and cost model

Every action is logged, and operating cost is tracked against the baseline from the first week.

Attributed example: built and operated by David

Bot for Kalshi: plain instructions become a rule graph you can read

Bot for Kalshi is a product David built and operates. It turns a plain-language instruction, such as a rule for when to place or cancel an order, into an explicit rule graph, with controlled, logged execution.

It is a paid product with its own support, payments and integrations. The Kalshi Bot Toolkit, its rule-graph engine, is public and MIT-licensed, so anyone can read and check the approach.

This is adjacent engineering. It was never an enterprise engagement. It shows the same approach we bring to a pilot: automation you can inspect and review.

  1. Stage 1

    Instruction

    A person writes a plain-language rule for what should happen and when.

  2. Stage 2

    Rule graph

    The instruction compiles into an explicit graph that anyone on the team can inspect.

  3. Stage 3

    Controlled execution

    Only the actions the graph allows are taken, each one logged with its inputs and result.

  4. Stage 4

    Review and revise

    Failures and edge cases surface for review, and the rule graph is corrected in the open.

Discovery, one workflow, a pilot, then a decision

Each step produces something you keep, whether or not you continue to the next one.

  1. Step 01

    Discovery call

    You keep We learn your systems, your access rules and what a good outcome means to you. You get a short written summary.

  2. Step 02

    Map one workflow

    You keep A map of one workflow: the data it needs, the actions it takes, and where a person reviews it.

  3. Step 03

    Scoped pilot proposal

    You keep A fixed scope: what gets built, for which user group, the baseline, and what it costs.

  4. Step 04

    Working pilot

    You keep A small group of your people use it against real data, with logging and a tested way to roll back.

  5. Step 05 / Gate

    Production decision

    You keep You compare the pilot against the baseline and the agreed criteria, and decide: stop, extend, or move to production.

    • Stop
    • Extend
    • Move to production
  6. Step 06

    Rollout and support

    You keep A staged rollout to more users, with maintenance and support agreed in writing beforehand.

The questions that decide whether this is a good idea

6.1Who owns the code and the rule graph?
You do. Everything we write for you lives in your repository. Where we build on an open-source foundation, we name it and its licence before you commit.
6.2Does a pilot automatically become a production system?
No, and we do not promise that it will. It ends with a decision made against the baseline and criteria agreed before it started. Stopping is a valid outcome.
6.3Who reviews the cases the system gets wrong?
A named person on your side, or one of us during the pilot. Every workflow needs somewhere for the case the rules did not anticipate to go.
6.4Who maintains it after the pilot?
That is settled before the pilot starts, in writing: who upgrades it, who reviews the rules, who answers when it breaks, and what that costs.
6.5What access do you actually need?
Only what the mapped workflow needs, scoped by your IT or data partner. We test a missing or revoked permission before the pilot begins, not after.
6.6Will it work with our CRM, ERP or document store?
That is most of the work. We list every system the workflow touches during mapping and test each connection in the pilot.

Seven things to know before you propose an AI pilot

You can gather these in an afternoon. They make the mapping call shorter, with us or with anyone else. If you are about to talk to firms, the guide to hiring AI consulting lists the questions to ask and what a good answer sounds like.

No.ItemKnownNot yet
01

The one workflow you would test first, and who does it today

02

The systems that workflow already touches: CRM, ERP, documents or a portal

03

Who owns the data the pilot would use, and who can grant access to it

04

What a passing result would look like, in terms you could defend to your own leadership

05

Who reviews the cases the system gets wrong

06

Whether you have engineers who would maintain a production system

07

What would make you stop the project rather than extend it

The full pilot acceptance checklist

Plain answers

8.1How long does a pilot take?
It depends on the workflow, its data access and its integrations. We set the length in the proposal, after the mapping step, and not before.
8.2What does a pilot cost?
We quote a fixed scope once the workflow is mapped. We do not publish a price list, because the scope decides the cost.
8.3What happens if the pilot does not pass?
You stop, or adjust the workflow and try again. A pilot that ends without moving to production is a normal outcome, and we say so before it starts.
8.4Do we need our own AI or data team?
It helps but is not required. An IT or data partner who can grant access and review the rules with us is enough.

Two people who have shipped software together for nearly ten years

Enterprise AI Pilots is a site of The Goodstack Company. There is no sales team and no delivery bench beyond the two of us. You talk to the people who write the rules and read the logs.

David

Engineering and delivery

David built and operates Bot for Kalshi, which turns a plain-language instruction into an explicit rule graph with controlled, logged execution. Its rule-graph engine, the Kalshi Bot Toolkit, is public and MIT-licensed, so you can read the approach before you hire anyone. He built it for himself and we say so plainly. It is the same discipline he brings to a pilot: automation you can inspect, review and switch off.

Vidur

Product and design

Vidur is the co-founder of Goodstack and leads product and design. He designed the original Goodstack and ran the studio with David. On AI work he owns the part people actually use, which is the review queue where a person checks an exception, and he has experience with SOC 2 compliance, which matters the moment a model is given scoped access to real systems.

About Goodstack

Start with one workflow

Tell us which workflow you want to test, who does it today, and what a passing result would look like. We will reply with what we would look at first.

Propose an AI pilot
  • 01The workflow you want to test
  • 02Who does it today
  • 03What a passing result would look like