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.
A pilot is a step toward production. We agree on what happens after it before it starts.
The pilot proved the model. The workflow is still unproven.
These are the blockers people describe in public when an AI pilot stalls.
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.
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.
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.
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.
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.
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.
- 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.
- 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.
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.
Instruction
A person writes a plain-language rule for what should happen and when.
Rule graph
The instruction compiles into an explicit graph that anyone on the team can inspect.
Controlled execution
Only the actions the graph allows are taken, each one logged with its inputs and result.
Review and revise
Failures and edge cases surface for review, and the rule graph is corrected in the open.
What this does not show. This is David's own product, not a Goodstack client engagement and not an enterprise deployment. We make no claim here about profitability, uptime or an endorsement from Kalshi. It demonstrates rule-based automation with review and logging built in, not a finished enterprise system.
Discovery, one workflow, a pilot, then a decision
Each step produces something you keep, whether or not you continue to the next one.
Discovery call
We learn your systems, your access rules and what a good outcome means to you. You get a short written summary.
Map one workflow
A map of one workflow: the data it needs, the actions it takes, and where a person reviews it.
Scoped pilot proposal
A fixed scope: what gets built, for which user group, the baseline, and what it costs.
Working pilot
A small group of your people use it against real data, with logging and a tested way to roll back.
Production decision
You compare the pilot against the baseline and the agreed criteria, and decide: stop, extend, or move to production.
Rollout and support
A staged rollout to more users, with maintenance and support agreed in writing beforehand.
The questions that decide whether this is a good idea
- Who 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.
- Does 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.
- Who 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.
- Who 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.
- What 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.
- Will 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.
- The one workflow you would test first, and who does it today
- The systems that workflow already touches: CRM, ERP, documents or a portal
- Who owns the data the pilot would use, and who can grant access to it
- What a passing result would look like, in terms you could defend to your own leadership
- Who reviews the cases the system gets wrong
- Whether you have engineers who would maintain a production system
- What would make you stop the project rather than extend it
Plain answers
- How 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.
- What 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.
- What 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.
- Do 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
David runs beLoved Health, a distribution company, and built the system it runs on: CRM, wholesale portal, invoicing, samples and affiliate payouts. He writes the code and runs the pilots.
Vidur
Vidur is the co-founder of Goodstack and leads product and design. He designed the original Goodstack and ran the studio with David. He has experience with SOC 2 compliance, which matters the moment a system touches a customer's data.
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.