We Gave an AI a Business to Run

Overview

What would it take for software to actually run a small business?

Not just answer questions about it, but actually run it.

A small business generates hundreds of decisions every week. How much inventory should be ordered tomorrow? Which supplier should get the order? Is today’s sales dip normal? How many people should work Saturday afternoon?

These decisions depend on each other, too. Demand affects inventory. Inventory affects ordering. Supplier lead times affect how much needs to be ordered. Demand affects staffing. An unexpected sales pattern can invalidate assumptions elsewhere.

Large businesses can afford specialized software and people for these problems. A small business owner usually can’t.

So we started with the question:

Could software learn enough about a business to fully operate it?

Exploring the question led us to Tally.

We gave Tally a simulated small ice cream shop and let it run for a full 365 days. It processed more than 26,000 sales, placed 124 autonomous orders worth roughly $18,000, published 52 weekly staff schedules with zero coverage gaps, and detected 409 operational anomalies.

Those numbers are interesting. What matters more is how we achieved them.

One Giant Problem

A business isn’t one enormous prediction problem. That sounds obvious, it has a big architectural consequence.

We could have tried to put as much of the operation as possible behind one large model and asked it to reason across sales, inventory, staffing, suppliers, and purchasing. But we chose a more unconventional approach: specialized systems, each built around the particular problem it needed to solve.

Instead, Tally is built from specialized systems that each handle a particular class of decision. A forecasting model predicts demand. An optimization solver handles staffing. Inventory is tracked through a persistent operational ledger. Anomaly detection combines deterministic rules with statistical checks. Separate logic governs authority. Reliability mechanisms watch the system itself.

That choice is technically important.

A forecasting model doesn’t need to understand how a staff schedule should be optimized. A scheduling solver doesn’t need to predict tomorrow’s weather. An authorization system doesn’t need to understand the semantics of an ice cream flavor. Each component gets a narrower problem. That makes the individual pieces easier to evaluate, constrain, and replace. More importantly, it lets us use the right, specialized technique for each job instead of forcing every problem into the same model.

The result is less like one artificial brain and more like a small operations team whose members have clearly defined responsibilities. And the hard part is making them work together.

Prediction Is Only the Beginning

Take demand forecasting.

Tally uses a machine-learning model to predict daily sales from signals such as weather, day of week, holidays, and seasonality. It then translates that daily expectation into product-level and hourly expectations so other parts of the system can use the forecast to make granular decisions with more precision.

The forecast also carries uncertainty.

That’s important because businesses don’t operate against a single predicted number. If the system expects 137 sales, the operational question isn’t simply “what happens at 137?”

What if demand is higher?

What if it’s lower?

Tally estimates prediction intervals from historical forecasting errors rather than assuming the errors follow a convenient theoretical distribution. A seasonal baseline also runs alongside the main model as a permanent benchmark.

The prediction model has to earn its place.

We evaluate it through rolling-origin backtests, and it only becomes the production model when it demonstrates a meaningful improvement over the benchmark, set by the user, while maintaining the required interval coverage.

This is a recurring design principle throughout Tally:

A component doesn’t gain trust just because it’s sophisticated. It must earn that trust because it demonstrates that it works.

And even then, the forecast isn’t the decision.

The system has to take the prediction, account for uncertainty, look at the current inventory position, consider supplier constraints and delivery timing, apply the business’s purchasing rules, and determine whether an order should actually happen.

Predictions Aren’t Always Reality

Inventory is maintained as a perpetual operational ledger rather than repeatedly guessing the current quantity from scratch.

The system starts from a physical count, accounts for deliveries, accounts for sales, translates sold products into their underlying ingredients, and estimates shrinkage. Physical cycle counts periodically anchor the estimate back to reality.

If the physical count is dramatically different from what the ledger expects, Tally doesn’t quietly absorb the discrepancy. It alerts the owner. That’s a small design decision with a big consequence. The system has to distinguish between new evidence and evidence that something is broken.

Ordering then builds on that trusted inventory state.

The system considers the expected demand over the relevant period it must cover, including the uncertainty around that demand, and compares it with what is currently available or already on order. It also respects supplier requirements such as order minimums and the physical realities of the products being ordered such as products coming in pack sizes.

Perishables are treated differently from durable inventory because ordering ten times too much of something that expires tomorrow isn’t a successful forecast. The point is that there isn’t a single “ordering model.” There is a chain of reasoning.

Forecast → uncertainty → inventory position → supplier constraints → purchasing decision

And then, a very critical question appears: Should Tally actually be allowed to do it?

The Freedom to Act

This was one of the hardest parts to get right.

Tally doesn’t start with permission to place orders autonomously. It starts in proposal mode. It calculates the numbers and informs the owner of the decisions it thinks the business should make.

The owner reviews its recommendations, approves some, edits others, and rejects others. Tally tracks that history separately for each supplier. A system can perform well with one supplier and poorly with another, so treating “ordering” as one global permission would throw away useful information.

As Tally accumulates evidence, it can propose that its authority be expanded to autonomy for a particular supplier and show the evidence behind that recommendation. The owner grants the promotion.

The reverse is automatic.

Repeated rejections, significant edits, or failures can cause autonomous authority to be revoked without waiting for another approval. That gives autonomy a direction. It starts narrow and expands only when the system has demonstrated competence. When the evidence deteriorates, authority contracts. And authority isn’t the only protection.

An autonomous order passes through two independent boundary checks. The ordering system checks whether the action is allowed. The component that actually sends the supplier email independently checks the limits on the order such as maximum autonomous order value set by the owner. The sender doesn’t simply trust the proposer.

Tally internally maintains a spending ledger that limits cumulative autonomous exposure, along with checks for novel or unusual behavior, such as an atypically large order, that can force human review even when an action technically falls within its spending authority. This matters because a system can make a perfectly valid decision according to its rules and still encounter a situation the owner never intended it to handle autonomously. The system makes unusual situations visible while minimizing the potential damage.

It Handles People, Too

Ordering is only one example.

For staffing, Tally takes its hourly demand expectations and translates them into required coverage. A constraint solver then works through employee availability, shift lengths, maximum hours, rest requirements, and more. Some constraints are non-negotiable, like employee availability and maximum working hours. Others, like having the ideal number of people on the floor at every hour, can be flexible.

If the available staff can’t satisfy every desired coverage slot, the system doesn’t manufacture a perfect-looking schedule. It reports where coverage is short and provides a diagnostic showing what constraint would need to be relaxed to resolve it.

That distinction matters. Real operations contain conflicts. A useful system should expose them rather than hide them behind an answer that looks complete.

Owner edits, once again, become evidence. If the owner repeatedly changes staffing decisions in a particular direction like increasing shift length, that feedback can influence the system’s future staffing assumptions within bounded limits. Which is evidence yet again, the model isn’t operating alone. It sits inside a decision process.

Sometimes, Simpler Is Better

This is another deliberate choice.

Tally’s anomaly system includes deterministic checks that work from the first day. Unusual refund rates, voids, discounts, supplier price changes, inventory discrepancies, and system-health problems don’t require a trained model to recognize that something deserves attention. However, they do keep track of history over time and adjust accordingly while weighing recent numbers more heavily than older numbers to keep the checks relevant.

Forecasting provides another layer. At the end of the day, and at an intraday checkpoint, actual performance can be compared with the forecast’s expected range. An alert isn’t just “something looks wrong.”

It carries the relevant evidence so the owner can understand why it fired an anomaly.

There are also mechanisms to prevent the system from repeatedly shouting about the same issue. Alerts have severity levels, deduplication, and cooldown behavior.

That may sound less glamorous than a sophisticated model. It is also exactly the kind of engineering that makes an autonomous system usable. A business owner doesn’t need hundreds of vaguely interesting alerts but the five that truly matter.

Proficiency Comes with Experience

Tally becomes better at operating a particular business through many small feedback loops rather than one magical learning mechanism. It models how a new employee would learn and improve at the job.

Forecast errors inform future calibration. Owner edits provide evidence about where proposals are systematically wrong. System estimation and physical count discrepancy estimates adapt. Anomaly sensitivity changes within controlled bounds. Supplier-specific performance accumulates. Different model candidates are evaluated against the incumbent.

The adaptive parameters share a common structure: a current value, limits on how far it can move, a decay rate for old evidence, and a history of changes.

But, it has limits placed on it which, again, are set by the user. Those limits are important. If a parameter repeatedly hits its boundary, Tally doesn’t keep pushing it farther in the same direction. It raises a structural-change anomaly.

In other words, the system can say:

“My current correction mechanism isn’t enough to explain what’s happening.”

That’s much healthier than silently adapting forever until it loses touch with reality.

There is also a distinction between fast and slow adaptation.

Small corrections can happen frequently as new evidence arrives. Larger model changes happen on a slower cycle and have to clear the same kind of performance evaluation used when the model was first selected. Each week the models are retrained with the newly gathered data. The current model is called the champion and a newer model is called a challenger.

A challenger doesn’t replace the current model because it is newer. It replaces it when the evidence says it performs better. In this way, each week, the system picks the best model for the job to maximize results.

Surviving Catastrophe

A business operator isn’t useful if it works only when everything goes perfectly. Following that principle, we designed Tally to be testable and recoverable. Every action passes through an explicit communication path before an email is sent. Supplier messages are represented as durable records first, which provides protection against duplicate sends if part of the system crashes at the wrong moment. Testing defaults to dry-run mode, so developing and replaying scenarios can’t accidentally email a real supplier.

Splitting the system into specialized components also creates a new failure mode: there are more things that can fail independently. One component can stop while the rest of the system keeps running, potentially producing incomplete or stale results.

So we implemented a simple solution to that: the system monitors its own health. Components report that they’re alive, and stale processes trigger alerts. An independent dead-man’s switch watches the notification path itself. If the entire application crashes, it can’t notify the user. But the dead-man’s switch can still raise an alarm.

This matters because email is Tally’s only way of communicating with the outside world.

After the system was built and each component was tested individually, we had to see if they could work together over a long period of operation. So we ran a simulation designed to mimic real operating conditions, including unexpected events, and tested how the system responded.

That last piece is particularly useful.

The simulation isn’t a demo environment sitting beside the product. It exercises the same kinds of operational pathways we care about in production and gives us a way to test changes against long sequences of business events.

Then We Gave It a Year

We ran the system for 365 simulated days using synthetic sales driven by real weather data from Open-Meteo.

The virtual owner was intentionally imperfect. It occasionally missed counts and approved things late. The synthetic sales had unusually low and high days.

Nothing was hand-tuned during the run.

Three suppliers were seeded. Each eventually earned autonomous ordering authority independently after Tally demonstrated sustained performance as it would in production.

Over the year: 26,000+ sales were processed. 124 orders were placed autonomously, worth roughly $18,000. Restock coverage stayed between 100% and 119%. 52 weekly schedules were published with zero coverage gaps. 26 owner schedule edits were incorporated into the staffing feedback loop. 409 operational anomalies were detected.

And the simulation found bugs.

An error in the demand forecasting pipeline caused systematic under-ordering until audit queries exposed it.

A reorder-point condition inherited from the deterministic inventory layer prevented proactive ordering during a seasonal demand ramp.

Inventory underflows exposed weaknesses in naive reconciliation logic.

These are why we ran the simulation.

A full-year test gives the system enough time to encounter combinations of events that are difficult to anticipate from isolated unit tests: seasonal changes, inventory discrepancies, model behavior, supplier delays, owner corrections, and failures interacting with one another.

The simulation didn’t prove that Tally is infallible.

It proved that we could put the whole operator under sustained pressure, inspect its behavior, and see how it responded to the challenges we had modeled.

Beyond Ice Cream

There’s another architectural decision hiding underneath the simulation.

The core engine doesn’t know it’s running an ice cream shop.

The business-specific information is represented separately in the simulation: products, suppliers, costs, inventory characteristics, staffing rules, operating constraints, historical information, and other business-specific assumptions.

The operational machinery sits above that configuration. The architecture is designed so that the core engine doesn’t need to be rewritten around each business’s products and operating rules.

That doesn’t mean every business is interchangeable. It isn’t. Different businesses have different data, constraints, economics, and operational quirks. Those differences have to be represented somewhere.

The important idea is that they don’t all have to become special cases in the core engine. Business-specific constraints can be added around the core engine when a particular operation needs them.

The ice cream shop is therefore a useful proof environment, not the boundary of the system. That separation is what makes the architecture useful beyond a single vertical.

Too Good to Be True?

While it is a carefully designed system that solves many real problems, it has limitations.

Inventory estimates have a physical noise floor. For example, in an ice cream shop, every hand-scooped portion varies. Weekly counts help anchor the ledger, but the system doesn’t pretend it can know the exact number of grams consumed.

Shrinkage learning depends on those counts happening. If the owner stops doing them, that feedback loop stalls. Tally can flag the missing evidence. But it can’t create it.

The five-minute daily operating target also comes after calibration. In the first several weeks, the owner reviews everything. The owner carries more responsibility during this period because the system hasn’t yet earned enough autonomy to reduce the workload.

Seasonality has the same problem. A business that opened yesterday doesn’t know what August looks like. Early correction mechanisms can help, but they can’t replace a year of history. Tally therefore begins conservatively, relying on owner configuration and approval while it accumulates evidence.

And some of the hardest production problems aren’t statistical at all.

Supplier email deliverability is one. If an order gets filtered into spam, a perfect purchasing decision is worthless. DNS configuration, SPF, DKIM, and spam filtering are mundane dependencies with very real consequences.

There is also a much broader limitation here: this is a simulation.

While we tried our hardest to model real conditions and challenge the model, the results demonstrate what the system did under the conditions we were able to think of. There are many problems that emerge in the real world that we cannot predict in advance and model for. The simulation cannot establish that every real business would behave the same way despite our best efforts.

That distinction is an important one to keep in mind.

So, What Did We Actually Build

The original question was whether software could run a small business.

After building Tally, we think the more interesting question is how.

Our answer wasn’t one enormous model that somehow understands everything.

We designed a collection of specialized systems, each chosen for the problem it actually needs to solve, connected into a single operational loop.

A forecasting model predicts demand. An inventory system turns transactions and physical counts into a current operating state. An ordering system turns demand and inventory into purchasing decisions. An optimization solver turns demand into staffing requirements. Anomaly detection looks for evidence that the assumptions are breaking. Feedback loops calibrate behavior. Authorization determines what the system is allowed to do. Reliability mechanisms make sure the system can survive failures. Simulation lets us run all of it forward through a year of business conditions. And the audit trail connects the pieces.

That architecture is the part we find most interesting about the problem.

We didn’t use massive state-of-the-art models. We used smaller, specialized models to solve a large problem, because each component could be evaluated against the specific job it was responsible for. The surprising part wasn’t that any individual component was extraordinary. The interesting part was what happened when specialized components were given narrow responsibilities, explicit boundaries, feedback loops, and a shared operational state.

A relatively modest model can be extremely useful when it sits inside a system that gives it the right inputs, checks its outputs, measures what happened afterward, and limits what it can do when the evidence isn’t strong enough.

Intelligence isn’t always in the prediction. It can lie in the machinery around the prediction.

Tally is one demonstration of that idea.

It can make decisions, execute some of them, evaluate outcomes, adapt to evidence, and progressively earn authority over specific parts of the operation.

And when it gets something wrong, we can inspect what happened.

That’s a much more useful standard for autonomous software than simply asking whether the model is impressive.

The real test is whether the software can be trusted with consequential decisions.