Most agent setups fail long before they need a bigger model: the job is vague, the Bot has too much access, and nobody checks the result. In Duncan Rogoff's video, six habits drawn from engineer Lauren Tan point to a smaller, more testable approach. The transferable idea is not her scale. It is to teach one agent a real task, check its understanding, and make successful work repeatable.
Start with one Bot and one task. Give it the same context a new colleague would need, ask it to restate the goal, and require observable evidence before accepting "done." Fix recurring failures in the workflow or a check; save a skill only after the task works. Keep decisions and writing that express your own judgment with you.
Watch Duncan Explain the Six Habits
Source Note: A Guide, a Video and a Product Manual
Checked 9 November 2026. Duncan's five-minute interpretation is the source for this six-habit ordering, the examples and the token-budget claim. Lauren's small-team guide and follow-up are the underlying posts; X restricted full-text access in this check, so we cross-checked indexed public reproductions and keep claims attributed. Grok Bot's documentation verifies how skills and routines work, not Lauren's personal usage figures. We did not inspect her private workspace, verify a pull-request count, reproduce the Bot workflow or measure her token spend.
Six Habits, Translated Into a Workable Setup
1. Keep the team small; earn each skill
Lauren's guide favors a few useful Bots over a large roster. Duncan's phrase "zero skills" is a starting condition, not a permanent ban: Lauren recommends turning instructions taught during real tasks into reusable skills. The official guide likewise says to make one task reliable before saving a skill and automating it. For a first test, do not install a pack of unfamiliar skills or create roles without distinct jobs.
2. Onboard it like a new colleague
Explain the audience, the task, examples of good work, constraints and who has final approval. Put stable facts in a maintained brief instead of expecting a fresh chat to remember them. Lauren's onboarding advice includes describing your work and asking where a Bot could help. Give access to one sample dataset first; connections to email, Slack or customer records are a separate decision.
3. Make it say the job back to you
Before work begins, ask the Bot to restate the goal, intended output, exclusions and open questions in its own words. Duncan's editing anecdote shows the cost of a plausible misunderstanding: "mark action" meant select highlights, not tag every movement. Correct the restatement while it is cheap, before an agent spends time or touches files.
4. Fix repeated errors at the lowest useful layer
A correction buried in one conversation is easy to lose. If a document format fails twice, change the template or workflow; if possible, add a deterministic check. Only then encode a repeatable method as a skill. Duncan describes this priority order in the fourth habit; Lauren's public P-Stack source shows how substantial a skills-and-verification system can become. You do not need to install that system to borrow the principle.
5. Ask for evidence, not a confident completion message
Define an observable finish condition: open the page, run the test, compare the output with the sample, or show a screenshot and the relevant file diff. Ask what passed, failed and remained untested. Duncan attributes to Lauren a preference for empirical checks over abstract second-agent criticism. Her later review comment is narrower than "never review": she objects to review without running the work or using a deterministic checker. Human review still matters for consequential changes.
6. Keep the thinking-heavy writing yours
Duncan says Lauren writes her own public posts because writing helps her clarify the thought she needs to communicate to agents. That is a personal practice, not a rule against using AI for drafts. A useful boundary is to write the goal, judgment and final approval yourself; let the Bot organize notes, check facts or propose alternatives without silently replacing your point of view. Watch Duncan's sixth habit.
Do Not Copy the Token Budget
Duncan cites extraordinary pull-request volume and daily token use as part of Lauren's context. Those are self-reported figures in the video, not independently audited measurements, and they are not a budget for a solo reader. A 15-minute routine can run 96 times in a day. Grok Bot's routine documentation says each run spends usage and recommends testing a safe manual pass before scheduling. Start with one manual run; if it succeeds, choose the slowest useful schedule, set a usage cap where available, and check the run history.
A One-Bot Test That Reveals Whether This Helps
Pick a repeatable preparation task, such as turning a sample bug report into a triage summary. Give the Bot an expected output and have a person score three runs for correctness, useful evidence and time saved. Stop if the reviewer spends more time fixing the output than doing the task directly. This is our editorial test, not a workflow Lauren or Duncan demonstrated.
Test a task before automating it
Sample data, human review and observable proof.
Video Chapters
Start with the job
| Time | Topic |
|---|---|
| 00:00 | Why Duncan studies Lauren's workflow |
| 00:28 | Keep the Bot team small |
| 01:05 | Onboard it like a new hire |
| 01:41 | Ask it to restate the job |
Make the work improve
| Time | Topic |
|---|---|
| 02:41 | Fix the setup, not only the chat |
| 03:19 | Require proof of the result |
| 04:08 | Keep the important writing yours |
Limits and closing
Sources by Role
- Video interpretation: Duncan Rogoff's six-habit walkthrough and the supplied transcript.
- Lauren's public notes: small Bot team guide, follow-up, and review-versus-verification comment.
- Product mechanics: official skills and routines guide and the public P-Stack plugin source.