Where Keel came from, and what it is now.

Part one · The original idea

The first version of this was submitted a couple of years ago, as a student at the University of Florida, to the Gator Hatchery Venture Challenge. It was a naive idea, written early in the current wave of language models, when the shape of what these systems could do was still unclear. The pitch was simple and, in retrospect, a little credulous: a chat interface that could give small-business owners and first-time founders the kind of tailored guidance that normally costs money they do not have. The whitepaper below is that original submission, preserved without edits.

EntrepreneurAI was framed as an AI-powered business consulting platform for entrepreneurs and small business owners. The first plan made three core claims:

• Traditional consulting is expensive and inaccessible. A chat interface with a language model could deliver the same guidance at a fraction of the cost.
• The product would cover a broad catalog of functions, financial analysis, market research, strategic planning, customer service, scheduling, and so on, so that one subscription replaced a dozen tools.
• The growth model was volume: affordable pricing, content marketing, and a long catalog of capabilities on a single dashboard.

We kept one piece of that: the conviction that operators of small, ambitious businesses are the people most underserved by current software. Everything else got thrown out. A chatbot that gives advice is not a product. It is a search engine with a friendlier tone. The operators we talked to did not want more advice. They wanted the work to move while they slept.

The rename to Keel was not cosmetic. It marked the moment we stopped trying to build a consultant and started trying to build an operator.

For reference, the original whitepaper that framed the EntrepreneurAI idea is preserved here in full: EntrepreneurAI.pdf. It is kept as a historical artifact, not as the current plan.

Part two · The 2026 whitepaper

What we think is true

The people we build for are running real businesses. They have customers, invoices, payroll, vendors, and a list of things they wish someone else would handle. They do not want a seat in an agent dashboard. They want the next correct action to have already happened by the time they sit down with coffee.

Most of the current wave of AI products miss this for one of two reasons. They either package intelligence as a chat window the operator has to steer, which creates a second job, or they promise full autonomy and make decisions the operator did not consent to, which creates a trust problem the operator cannot afford.

We think the right shape sits between those. The operator describes what the business is trying to do. The system does the work that is safe to do. When something is irreversible, costs money, or speaks on the operator's behalf, the system pauses and asks. Everything else keeps moving.

How the system is built

Each business gets its own workspace. A workspace is a private, per-venture environment with its own memory, its own connected tools, and its own running record of what has been done and why. If the operator runs two businesses, there are two workspaces. They do not share state. They do not talk to each other.

Inside each workspace, work happens in turns. A turn is triggered by the operator, by a schedule, or by an inbound event like a new inquiry or a low-stock signal. Each turn spins up a fresh process, runs the work, writes the outcome, and exits. Nothing about one turn is allowed to leak sideways into another. Restarts are cheap. State is explicit.

Memory is per operator and per venture. The system remembers what it learned about the business, the customers, the vendors, the pricing, and the operator themselves: how they like to be spoken to, what they care about, what they have already been asked. That memory stays private to the workspace it lives in.

The piece we care most about is the trust contract. When the system is about to do something that touches money, sends an email in the operator's voice, files with a government, or otherwise cannot be undone, that action does not execute. It is written into a pending queue the operator reviews. The operator can approve it, edit it, or reject it. The system learns from the pattern. Over time, for a given class of action, the operator can tell the system to stop asking. That choice is always theirs.

Nothing about this is magic. It is the careful, boring work of drawing the line between actions a machine should handle and actions a human should sign off on, and holding that line in every turn.

What this enables

The operator gets to choose what they want to spend their attention on. That is the whole point. A designer who wants to spend Tuesday designing spends Tuesday designing. A restaurant owner who wants to spend the morning on the line spends the morning on the line. The business keeps moving. The books stay current. Inquiries get answered. Renewals get drafted. Things that need the operator's judgment come to them cleanly, with context, and not one at a time all day long.

The operator ends up sharper, not busier. The product is not a cleanup crew running behind them. It is a partner that holds the state of the business and returns their time.

What Keel is not

Keel is not a chat interface. There is a place to talk to the system, but talking is not how work gets done. Work gets done in turns, by the workspace, whether the operator is watching or not.

Keel is not a no-code workflow builder. The operator does not design pipelines. They describe outcomes and constraints. The system is responsible for choosing how.

Keel is not a general-purpose autonomy product. We do not aim to run any business, on any stack, for any buyer. We aim to run the kinds of small, real businesses whose operators deserve a partner and do not currently have one.

Keel is not a law firm, a CPA, or a licensed financial advisor. Actions that require a license are performed by partners whose terms apply alongside ours. The system knows where that line is and will not cross it quietly.

Where we are

As of today, Keel is in private onboarding with a small group of operators across services, retail, hospitality, and studio practices. The workspace runtime is live. Every outbound send is reviewed against the operator's trust contract before it goes. Per-venture memory is live. We are learning the texture of what the system should and should not do by watching real businesses use it, every day.

We will expand access when we are confident the product clears the bar we set for it: the operator ends each week with more of their attention back, and nothing irreversible happened without their consent.

If you run a small business and any of this sounds like what you wish you had, we would like to hear from you. There is a waitlist at the bottom of the home page. We read every note.

Keel · 2026-04-22 · hello@runkeel.com