Skip to content
newc0

Answer

Can an AI-run company handle real customers and real money?

Yes for the volume and no for the commitments. Software handles orders, tickets, invoices and follow-ups well. Refunds, disputes, anything legally binding and anything irreversible should stop for a person. The safe design is not better models, it is a hard boundary between execution and approval.

Last updated

What can go wrong with real customers?

An agent answers confidently and wrongly, and the customer believes it. That is the whole risk in one sentence. It is not that the software refuses to help; it is that it helps convincingly with an answer that commits you to something you did not agree to.

A support agent that invents a returns policy has created a customer expectation you will probably have to honor. One that promises a delivery date has created a contractual position. Neither of these looks like a failure at the time — the ticket closes, the customer is satisfied, and the problem arrives later.

The mitigation is narrow scope and honest escalation. An agent working strictly from your own documentation, escalating anything it cannot support with a citation, is a good support function. One improvising is a liability with a fast response time.

What about handling money?

Take payments automatically, decide about money manually. Charging a card for an order the customer placed is routine. Issuing a refund, granting credit, or spending above a threshold is a decision with a consequence you cannot reverse, and it belongs with a person every time.

The asymmetry is the point. Money coming in follows a customer’s own action and is reversible through normal mechanisms. Money going out is a judgment, is usually irreversible in practice, and is the category where an automated mistake compounds quietly — a refund rule slightly too generous costs you every day until someone notices.

Advertising spend deserves its own threshold, because it is the fastest way for an automated system to spend real money without anyone deciding anything. Set a number you would notice, and make sure nothing above it moves without you.

What makes the difference between safe and unsafe?

Whether the boundary is structural or a matter of prompting. A system where irreversible actions cannot execute without approval is safe by construction. A system where the model has been told to be careful is safe until the day it is not, and you find out afterwards.

This is the single most useful question to ask any vendor in this category: is the approval gate enforced by the system, or is it an instruction to the model? The answers sound similar and behave completely differently under pressure.

The same logic applies to what the model can touch. A model that proposes changes which a deterministic executor validates and applies is a different risk profile from one with direct access to a filesystem or a network, regardless of how well-behaved it usually is.

Should customers be told they are dealing with software?

Yes, and increasingly you may be required to. Beyond compliance, it is simply better business: customers who know they are talking to software ask differently, escalate sooner, and are far less angry when it gets something wrong than customers who thought they were talking to a person.

Platform terms typically make this the customer’s responsibility rather than the vendor’s — you are responsible for the notices and disclosures your own end users receive, including any notice that automated systems generate content or take actions affecting them. Read that as a task, not a formality.

The practical version is undramatic. Say that replies are handled by an assistant and that a person is available. Give an obvious route to reach one. Do not give the software a human name and a photograph, which is the specific choice that turns a reasonable disclosure into a misleading one.

This is also why newc0 does not give agents human names anywhere. An agent runs a function. Making it look like a colleague creates exactly the impression that disclosure exists to prevent.

How newc0 draws the line

Agents execute continuously and queue anything binding, irreversible, above the founder’s spend threshold, or touching pricing and positioning. The generation side works the same way: the model proposes structured file-edit operations and a deterministic executor validates and applies them, so the model never touches a filesystem or a network directly.

What each function runs, and what it never does without approval, is set out on the agent workforce page.

Written by newc0. Published .

Every claim on this page is recorded on the claim sheet, with its scope. If the two ever disagree, the claim sheet is right and this page is a bug.