Reading Zeng Ming’s discussion of a “60-point threshold” brought me back to a practical question: before we talk about making AI better, can it perform one real piece of work?
That question struck a nerve. Many AI demonstrations look capable of everything. Put an actual job in front of them—such as the overseas customers I follow up with—and I still hesitate to let go.
AI can talk and write. Entrusting it with a complete task is another step.
Sixty points means ready for a job, not an acceptable error rate
The metaphor is separate from the quality of anything we send to a customer.
An email with an incorrect fact, an incorrect price or an excessive promise must still be rejected. AI may improve over time; customers should not have to pay for our learning.
Readiness means answering different questions. What do you give it, and what must it return? What needs verification? If it cannot find an answer, will it leave a gap or invent one? Will it stop and ask when uncertain? Who remains responsible for a mistake?
If those questions are unresolved, a more powerful model will not settle them.
Between answering and delivering lies an acceptance check.
Complete one small task from beginning to end
I learned this the hard way.
AI initially helped me write some promising outreach emails. I took that as a reason to add customer research, quotations, reminders and pro forma invoices. A little more today, another piece tomorrow. Within days, the whole chain became a mess.
Eventually, I reduced the task.
No quotations. No sending email. Start with a business card, meeting notes and public information I have checked, and return one customer record. Attach sources to facts. Mark unknowns as requiring confirmation. Tell me what is missing and what the next email should ask.
The task is small enough to inspect and to locate errors. It still has a beginning, an end and something saved afterwards.
That is what end to end means to me now: the chain need not be long, but its result must be contained and reviewable.
When it makes a mistake, improve the working rules
The smoother an answer sounds, the more carefully I read it.
“Might purchase 24 units” can become a confirmed requirement. Information absent from a customer’s website can turn into a plausible explanation. A polished document can hide the error.
I therefore put explicit rules into the process: separate facts from inference; leave unknowns blank; do not advance past an unclear requirement; keep email as a review draft. The send button stays with me.
Broadlatus has not reached the point of learning autonomously from every use. It first installs trade skills on the computer and preserves the outputs of the work. When you identify an error and report it, we can revise the skill. People remain involved and responsible.
A mistake that never returns as feedback is likely to be repeated.
Give it one job before expecting an entire team
If you want to try, do not start with a large system.
Choose one recurring task whose errors you can recognize. Try ten real cases. Record omissions and points where a person must take over, including the disappointing results. This is a way to begin testing, not evidence that ten successful cases establish readiness for every business situation.
Those specific failures are the feedback I want. “Looks good” gives me little to change. Show me where an unconfirmed detail became a fact, and the next version can address that failure.
I do not know which products will endure. I would rather spend time on a smaller question: can we prevent this particular mistake from happening again?
First complete one small task. Leave replacing a whole team for another day.
Tell us about a task through the website’s feedback and co-creation entry. See download and installation guidance for the current desktop app, included skills and requirements.