A system of record preserves the authoritative state of a business process, while a system of action helps execute the work around it. A small startup can begin with either role, but should make the boundary clear before it automates consequential decisions.
The distinction is useful because many attractive AI demos sit between the two. They read a customer record, generate a recommendation, and send an update elsewhere. That looks like one flow on screen. In practice, it contains several different responsibilities: knowing the current state, deciding what should happen, obtaining permission, executing the change, and confirming its result.
Choose the responsibility you can actually own
Bessemer uses the phrase systems of action for a thesis about AI software doing work around, and potentially replacing, established enterprise records. That is a market perspective rather than a requirement that every new product replace a core platform. Read the original roadmap.
Our recommendation for a solo founder is narrower. Identify one valuable action and make its completion understandable. You might prepare a supplier request without approving the supplier. You might draft a collection reminder without changing an invoice balance. You might identify missing onboarding information without declaring someone compliant.
A small, explicit responsibility is often easier to buy than a sweeping promise to run an entire function. It also lets you discover the exceptions before you inherit every failure in the surrounding process.
Map the boundary before writing the agent
Start with five boxes on paper: input, decision, permission, action, confirmation. For each box, name the person or system that owns it.
The source record may belong to the customer's accounting tool. The recommendation may be produced by your application. Approval may belong to a manager. Delivery may depend on an email provider. Confirmation may arrive later from a separate service.
If you cannot say who owns a box, automation will not remove the uncertainty. It will move the uncertainty into software, where it may travel faster and become harder for the customer to notice.
A completed API request is not necessarily a completed business job. The recipient may never receive the message. A remote system may accept work for later processing. A timeout may leave the result unknown. Your interface should represent those states honestly.
A hypothetical example: overdue invoice follow-up
Imagine a founder builds an assistant for a small services company. It reads overdue invoices, prepares reminders, and asks the finance owner to approve them. The accounting product remains the source of truth for payment status.
Before sending, the assistant refreshes the invoice state so that a payment recorded after drafting can stop an unnecessary reminder. After sending, it records the delivery reference and the approved wording. If delivery is uncertain, it shows that uncertainty rather than inviting a second blind send.
The example illustrates a design choice, not an actual implementation or promised result. The product's initial value is a reliable approved follow-up, not autonomous ownership of the customer's entire collections process.
Stripe's API documentation describes idempotency keys as a way to retry supported requests without accidentally repeating the same operation. The broader lesson is to understand the specific retry guarantees of each service you use. See Stripe's idempotent request documentation.
Measure completed work and correction burden
An action product can generate plenty of activity while making the customer busier. More drafted emails or more agent steps are not persuasive if staff spend their afternoons checking and correcting them.
Choose a customer-relevant unit of work. For the hypothetical assistant, that might be an eligible reminder sent with approval and a clear record. Then track exceptions: reminders stopped because the source changed, drafts rejected, uncertain deliveries, and manual interventions.
This is our proposed evaluation framework, not an industry benchmark. Its purpose is to make invisible supervision visible. If human review costs more than the work saved, you have found a product problem worth addressing before increasing autonomy.
The counterargument: a recommendation may be enough
Not every product needs to execute actions. A well-timed, well-supported recommendation may be valuable precisely because the buyer wants to remain in control.
Full automation can also increase sales friction. A customer may be willing to let a new company read selected information but unwilling to grant write access to a critical system. Starting with a read-only assistant is not necessarily timidity. It may be the right commercial and operational boundary.
Equally, do not call an ordinary dashboard a system of action simply because the phrase sounds current. Tell buyers what the product actually does.
Your action boundary checklist
Before moving from recommendation to execution, answer these questions:
- Which source decides the current state?
- How recent must that state be before acting?
- Who grants permission, and when does it expire?
- Can the same action happen twice after a retry?
- What does success mean beyond the first response?
- How will the user see partial or uncertain outcomes?
- Can a person stop future work and recover completed changes?
A useful first product can own one small action extremely well. Earn the right to take on the next one through evidence, not a bigger automation claim.