Alibaba’s Apsara made me think less about faster coding and more about who checks the work when the agent keeps going.

I spent three days in Hangzhou at Apsara, listening to Alibaba talk about everything from chips to agents to a computer that I now wish I could buy. Eddie Wu called AI coding the first light bulb. That landed with me because I build products with AI every day. The light is useful. I use it. But a lit room is not a working company.

I came home with an uncomfortable question for the work I do at Wize: if Alibaba can sell more of the plumbing ready to use, what exactly should a customer still pay me for?

I sat down with the people shipping my tool

Qoder is one of my main tools. I sat with its team at the conference and learned that they aim to ship an update every day. Poor guys. I also understood why it keeps changing under my hands.

Vibe Coding lets me take an idea, make the product, fix bugs and keep going without waiting for someone else to start the code. That is a real change in my working day. But I can still build the wrong thing faster. A company does not run itself because I can put a screen in front of a customer.

Alibaba’s QwenWork demonstration pushed the next part: Vibe Working. An agent opens files, uses tools, handles a sequence of tasks and hands work along. The useful question is not whether it can produce a nice document. It is whether it knows which version of a document is valid, whose approval is required, what it may change and when it has to stop. Leave those rules in someone’s private prompt and the rest of the team cannot inspect or reuse them. Put them into shared skills and workflows, and there might be a business process there.

I am in the One Person Company group myself, so I care about the third part, Vibe Business. Vibe Coding makes the thing. Vibe Working makes the work run. Vibe Business turns it into a business before I have every department staffed. That does not mean I outsource responsibility to an agent. If the customer gets a bad result, they will not argue with my workflow diagram. They will call me.

A product I built is becoming a shelf item

Smart Studio and Smart Fusion hit my own business directly. I built a multi model platform with routing, credits and cost control. Alibaba showed a way to package and bill model services under your own brand, and to route work across models through one interface. Much of what I had to build is becoming something you can buy off the shelf. Laughing through tears here 😂

Alibaba said on stage that Smart Fusion could reduce token costs by 40 to 90%, depending on the task. That is their claim, not a discount I would paste into a customer proposal without testing it on the customer’s work. The unpleasant part for me is simpler than the percentage: if I sell model aggregation with a different logo, why buy it from me? These tools lower my setup cost and my competitors’ setup cost at the same time.

I can still use that plumbing. I just need to earn the extra money by making a customer’s work finish correctly, connecting to their existing systems, and reducing the pile of fixes a person has to chase. Distribution matters too. Nobody pays extra because I memorized the model menu.

On a film set, the queue moved to judgment

I am doing AI video now, so I went looking for the awkward questions behind the demos. Can a character keep the same clothes across shots? If I revise a scene, what else changes? How many generations do I throw away before a client accepts the shot?

At the ARK session, the team did not pretend that generating frames settles those questions. Script, storyboard and production can overlap with AI. The bottleneck of an AI film set is judgment: which shot to approve, which to cut and which to generate again. The team described finishing the image generation system and then spending much longer getting the film to hold together. They talked openly about that too clean uncanny look and characters or sets drifting between shots.

That felt more useful to me than a claim about maximum video length. A long video nobody can sign off on is a long revision job. I want an agent to flag continuity changes across the story and send only the suspect shots to a human. I would rather review an actual mismatch than watch the whole thing again because a jacket moved.

The price tag I actually want

Alibaba sells more than model calls. An agent that browses, reads files, runs programs and keeps working uses compute, storage, databases and network capacity too. A cheap token does not make a cheap job if the agent fails and starts over. An expensive model might be cheaper if it gets an acceptable result with fewer retries.

My metric is cost per verified task, not token price. I want to know whether the task actually finished, how often a person had to repair it, how long it took and what the accepted result cost. That applies to the video shot as much as the customer document. It also forces me to say what verification means before I start celebrating automation.

Alibaba showed research where agents run experiments and check their own results. The tempting thought is that work I previously ruled out as too expensive might become worth doing. But there is a difference between a research demonstration, a product I can use today and a roadmap. I do not want to combine percentages from different demos and call it a business case.

The computer I could not buy

I tried the Qwen Book prototype myself. Its OS looks like macOS, it felt smooth, and I would have bought one to play with if it had been on sale. It was not. Sad. What interested me beyond the interface was the idea of the OS holding the context and controls the agent needs to act without pretending that every instruction belongs in a chat box.

China’s strength at Apsara was not simply another model score. I saw Alibaba trying to fit chips, cloud, models, agents and products into work that already exists. That matters to me more than a benchmark table. I also saw how quickly my own platform’s plumbing can become a standard product.

I sleep less this year. AI vampire, apparently 🥹 There is too much to try, especially with video. Still, less sleep is not a business model. I have to choose jobs people will pay to finish, write down the decision rules, and stay responsible when the result breaks. That is the work after the light bulb.

Botroom: Inside a company run by bots.

I run a company in Bangkok with 30 agent bots. Seven of them run the company day to day: Chief of Staff, CMO, CTO, ContentOps, B2B Sales, PM, and Researcher. This newsletter is my log. What they did, what failed, what I changed.

The bots route their work through a Chief of Staff bot. One rule: nothing gets sent or published until I approve it. As of this week, every post goes onto a Notion Content Approval Board. I either set it to Approved or leave feedback. Only then can the bots schedule it.

This week in the Botroom

The CMO bot scheduled a batch of posts for two content sites the bots run. Everything looked done. Then I saw the time. It picked a slot I would never pick, when my readers are not reading.

That was on me. I knew when my readers show up. The rule just lived in my head, so the bot had no way to know it.

We moved the posts. The CMO bot wrote the posting time rule into its memory and told the PM bot so the next batch is set right. That time was never the bot’s call. It was a default I should have written down on day one.

The agent did what it was told. If I know when my readers read, that rule can’t live only in my head. The board catches a bad batch. Written defaults stop the next one.

3 use cases worth stealing

In Muse’s Facebook Page workflow, a small-business tester had Muse rank recent Page posts using only figures from its Facebook connection, then write a caption in her voice, make an image, and schedule or publish. She said its analytics matched Meta Business Suite and rated it 8.2/10. A typo in the image reached the live post, and at one point Muse said her Group did not exist. Check the image, not just the numbers.

For LINE OA promotions through chat with Claude, Thai outlet Marketing Oops! connected Claude Desktop to a LINE Official Account through LINE’s Bot MCP server. The workflow checks quota, drafts three promos without sending, builds a Flex Message, exports JSON for LINE’s simulator, then broadcasts. There are no reported open or click results. Use a test account, keep the token out of prompts, and have a person approve any broadcast.

In a Monday newsletter workflow with Lindy, a newsletter writer set a Monday 9am trigger. The agent researches the week’s news, drafts the newsletter and social posts, saves them to Airtable, and emails her the draft. She said setup took under ten minutes, but shared no sample output or engagement data. Treat it as a drafting setup, not proof the writing is good.

What broke

We tested an SEO tool against our main writer on a Thai Facebook post based on a real article. It missed the source article’s specifics. It added claims the source did not support, repeated keywords, and put six internal links in the middle of sentences. The links broke the grammar. Even with a short preset, it produced an article format. Our main writer used details from the article and kept the caveats.

So it gets a smaller job. We keep it for research: keywords, clusters, and search opportunities. Not for drafting posts. We deleted the test draft and preset. Nothing from that test was published. The draft didn’t need a better opening. It made claims we couldn’t back up, and that’s a much worse problem to edit.

I also sampled 20 pages in our free use-case library at wizeos.ai. The basics are there. Every page has a source link, a label saying who made the claim (Vendor says, User reports, or Hands-on review), a “worth knowing” section that says what broke, and a prompt you can copy.

Then the gaps. Most cases are Western vendor or enterprise stories. The English slugs have zero cases for Shopee, Lazada, clinics, or real estate, and one LINE OA case. The pages do not give numbered setup steps or a “what you need” list. The “Have Wize set this up” button does not lead to a matching team template. We have zero “We ran it” cases from our own company. The Thai pages read like translations.

I want the library to help a small business here, not just collect interesting stories. The plan is a new page template with numbered steps, a downloadable team template, a human approval point, and a deploy button mapped to the right team. We will add a “We ran it” label and a Thai SME pack. Those are plans, not features you can use today. This newsletter is where our “We ran it” cases will show up first.

Template drop

The Content Studio team is described on the Grok Bot teams page. Its shape is ResearchOps, ContentOps, and CMO. ResearchOps finds sources (on our team, that is the Researcher bot). ContentOps drafts. CMO schedules after a human approves on a board. Write down the defaults too, starting with when to post.

Start with the approval point and the defaults, not the bot names. A team chart won’t catch a post set for the wrong time. A person on the board will, and a written rule keeps it out of the next batch.

Then reply with the one job you would hand an agent first. The actual task, not the job title.

Wora

kaize (@0x_kaize) wrote a practical guide to saving tokens in Grok Bot without upgrading your plan. We adopted several of those rules at Wize.

What stuck with me was the work you do not see. A message can trigger tool calls, retries, and another reading of a conversation that keeps getting longer. The reply is only the visible part.

Use the connector before the browser

When a bot needs records from a service, I want it to check for a connector or API path first. In a browser, it has to navigate, inspect the screen, choose where to click, and check whether the click worked. A changed layout or a login can stop it along the way. A connector can request the records directly.

Kaize cites a comparison: a browser agent took 53 steps, about 551,000 tokens, and 17 minutes. The API path took 8 calls, about 12,000 tokens, and 20 seconds. I would not treat those figures as a promise for our workflow. They do make the tool choice hard to ignore.

So our instructions say to use the direct integration when it can do the job. Use the browser when the task needs a human-facing interface. If permission is missing, report that instead of poking at the page again and again.

Give the bot a whole task

A vague request usually buys you a longer conversation about what you meant. Corrections can send the bot back through earlier instructions and tool results. Kaize cites a Cursor employee’s account of busy bots re-reading 80,000 to 90,000 tokens per step. That is a warning about oversized history, not a measurement of our bots.

I give a specialist the objective, source of truth, boundaries, and deliverable together. For an inbox task, I specify which inbox or label to check, what qualifies for action, whether to draft or send, and where the result should go.

I do not pack unrelated requests into the same prompt. One whole task per message gives the bot a finish line I can review. If the brief changes substantially, I restate it rather than keep patching an old thread.

Keep the reply short and the failure obvious

I do not need a diary of every click. I need the result, any decision waiting on me, and the location of the detailed artifact. Long chat transcripts give the bot more to read next time. They also make scanning the team feel like sitting through a meeting for every completed task.

A short reply still has to tell me when something broke. If a page fails or a connector refuses access, the bot should stop after 3 failed attempts. Tell me the failed action, the error or obstacle, and what remains unfinished. If I need to fix a permission or approve a login, hand it back to me. Do not improvise around it.

This matters even more for scheduled work. A routine can quietly loop over a broken source, consume attention and tokens, and leave me with nothing useful.

Schedule around decisions

A scheduled bot does work even when there is no news. Kaize’s math is blunt: a routine every 15 minutes runs 672 times a week, compared with 168 on an hourly schedule. He cites a Chinese user who measured this pattern. Even a check that ends with “nothing changed” has a cost.

Before scheduling something, I ask who needs the update and what they would do with it. If nobody needs to act between reviews, I prefer fixed, low-frequency runs that gather changes since the last run and return actionable items. When I stop reading a routine’s output, I should pause it or give it a narrower job.

The schedule belongs to a specific task, not a general bot told to inspect everything. Urgent exceptions can come through an event or a direct request. That does not make every check urgent.

Keep the role stable and put changing context in files

A bot description should say what the bot does, where its boundaries are, which tools it uses, and how it reports back. This week’s priorities, the current campaign brief, and working documents can live in files it reads when needed. If I edit the permanent description whenever a priority changes, the starting context becomes harder to audit.

There may be a caching benefit too, though I would not claim a specific saving for our setup. Grok 4.6 API cached input is $0.50 per million tokens versus $2.00 per million uncached, according to xAI pricing cited by kaize. API prices do not tell us exactly how a Grok Bot plan accounts for our work. They do show why repeatedly changing a shared prompt prefix may matter.

The practical benefit is clearer: a research bot knows what it may gather, and a writing bot knows which source material to use. I can change a brief without changing either bot’s standing rules. Each bot should read the files its task requires, not absorb the whole workspace.

Let the coordinator coordinate

I part company with one of kaize’s warnings here. He cautions against a chief of staff bot becoming the place you ask about everything. Fair. That bot can end up with a sprawling chat and too much work on its own desk.

But a coordinator helps our AI C-suite when it routes work to specialists, collects compact results, and flags decisions for me. It should not browse for every answer, draft every document, or carry all the project detail in its own chat. Kaize’s own bot-manager discussion supports that narrower setup: coordination works when the substantial work happens elsewhere.

Routing costs resources too. I am not sending a trivial task through a committee to make the org chart look tidy.

Before I add another bot

• Does it have a distinct job and a clear handoff?

• Can it use a connector before opening a browser?

• Can I give it the objective, inputs, limits, and deliverable in one message?

• Will it return a short result and stop after 3 failed attempts with a useful blocker report?

• If it runs on a schedule, is that schedule fixed and low-frequency? Will I pause it if nobody reads the output?

• Are its standing instructions stable, with changing context in task files?

• If a coordinator routes the task, is a specialist doing the actual work?

That is the arrangement at Wize. The bots can do plenty. They also need to know when the job is someone else’s, and when to hand it back to me.