xAI launched Grok Bot in August as "AI teammates you can give real work to." Meta launched Muse in September with a similar promise: give it a goal and let it act across the apps you use. People are responding. A report citing a company presentation put Grok Bot at 418,000 weekly users as of September 14. Third-party estimates put Muse at 2.8 million mobile installs in its first 12 days, and it reached No. 1 on the US free iPhone chart. These are early figures measuring different things, but the interest is real.
People are getting remarkably far with these agents, then running into familiar problems. The bot burns through its usage allowance, misses a step, does something the user never asked for, or keeps going when the job should be finished. The same freedom that lets it take a vague instruction and do useful work gives it room to make those decisions badly.
Grok Bot and Muse are especially useful when you have a job but have not mapped its route. Once that job comes back, what do you do with the route the agent found? Which decisions should the model still be making every run?
How does thinking happen?
Agentic or agents. You give an agent a goal and it decides what to do as the job runs. It looks at what it knows, picks a tool, reads the result, and decides on the next step. It can change direction when a source is missing or a website behaves differently than expected. It also decides when it has enough information and when the work is done. That is the impressive bit of Grok Bot and Muse. You can hand them a job without first writing down every step.
Say we're comparing alternatives to a vendor once. We do not know where the useful evidence is or which candidates will survive the first pass. An agent can search, follow leads, discard bad ones, and change its route as it learns. Spending model effort on finding that route is part of the job. Writing a process beforehand would take more work than doing the research.
It also means the job is solved fresh every time. The agent works out the flow while it runs, including decisions it may have made perfectly well the day before. Even a straightforward tool call goes through the model: it chooses the tool and its arguments, reads the result, then decides whether to make another call. Those turns take tokens and often carry more context as the job grows. If the model has an off day, it may take a worse route through the same work. Change the model and the route may change again. An early choice affects what the agent sees next, so small differences can cascade through the whole job. That is a reasonable cost for research whose path we do not know. It is harder to live with when the job needs to run under the same rules every Tuesday.
Deterministic work
For the last several years, we've distinguished this from deterministic AI at qbash. In a deterministic Task, the repeatable decisions and flow are worked out beforehand and encoded in a Python script. We haven't removed the thinking; we've moved those process decisions into the work of building the Task. Code orchestrates the steps, applies the checks, and calls a model for the judgments needed along the way. The model can return different answers, but it does not need to work out how to run the whole job again. For a defined process, that usually means fewer model calls spent on orchestration, less variable cost, and a faster run.
Take a sales pipeline running twenty times a day. Each record needs the same checks, a CRM update, and an alert when a condition is met. Or a job that watches for a particular event, or transforms a stream of documents in a known way. We can describe the route and what should stop it. We want the model's judgment where it is needed, without burning tokens to work out the whole process on every run.
The Jira triage comparison on our homepage shows this in code. The agent gets instructions to find open, unassigned issues, choose a team and priority, handle duplicates and uncertain cases, and alert on outages. The Task fetches tickets, loops through them, calls a saved prompt for the team and priority, then updates Jira. The code shown is the core path. To handle the agent prompt's exceptions, we would have to write those rules and checks into the Task too. That is the tradeoff: someone must define the process, and you can see which parts have actually been defined.
It also gives us a place to stop. If a Task is classifying emails and the model returns a category we did not allow, it should pause before moving anything. If financial records do not reconcile, it should stop before writing the result. If an SEO page is missing the research it depends on, it should not publish a plausible-looking page anyway. We want to know which step failed, inspect its input and output, and decide what happens next. Getting all the way to the end is not a success if the process crossed a failed check halfway through.
The cost is that someone has to understand the process well enough to write it. Sometimes we do not know the route yet. A Task preparing an SEO report might know which pages and candidate keywords to examine, how to score the findings, and where to deliver the report. Researching search demand for an unfamiliar niche, finding related queries, and judging which sources are useful may need a more open-ended investigation.
That is why we now support agentic Tasks as well. The Python Task can hand that research to an agent Task, require sources and a structured result, then check the required fields before it scores anything or delivers the report. If the research is thin or contradictory, it can stop or send the case for review. The check cannot prove an estimate is true, but it can prevent an incomplete answer from quietly becoming a published result. The agent gets to choose a path through the unknown part of the job; code still owns the parts we already know.
Grok Bot and Muse will make it easier for people to discover jobs they can hand off. Some will be singular, messy jobs where the route is unknown, and an agent is exactly right for them. When one of those jobs becomes a recurring process that matters operationally, look at which decisions the agent makes again on every run. Some will still need its judgment. The repeatable ones are candidates to write down, test, and keep steady while the model and the rest of the world change.