You're using AI agents wrong

Technological concepts & workflow/product features highlighted

1) Browser access for AI agents (dependency on web browsing)

• Argues that if an agent can’t access the real web, it’s significantly less capable because most of the web (~80%) isn’t reachable via simple “curl/fetch over existing APIs.”
• Uses Browserbase as a solution:
  • Provides an agent-friendly browser (simple search + URL context fetching).
  • Supports end-to-end interactions (clicking buttons, signing in, completing real actions).
  • Adds value for testing and preventing regressions by running agent-driven flows continuously before users hit bugs.
  • Mentions Browserbase also helps avoid common stuck points (IP blocks, CAPTCHA issues).

2) Skill invocation behavior: $ vs / in Claude Code / Cloud Code

• Key bug/behavior difference:
  • Using $ to trigger skills works for many skills, including those in/outside the project.
  • But if a skill is configured as “manual-only”, it won’t trigger correctly via $; it requires the / slash-command form.
• The speaker identifies this as a previously unknown “legit bug” and plans to fix/validate it.

3) Multi-thread / multi-agent execution patterns

• The workflow relies on repeatedly spawning new agent threads to parallelize work:
  • Thread creation is done via hotkeys; then input is added (including voice-to-text using Whisper Flow).
• Strong emphasis on not bottlenecking on local hardware:
  • Recommends running agent work on a separate Linux box to avoid slowing down the laptop.
  • Notes Mac OS is less reliable for heavy parallel agent workloads; Linux yields better CPU utilization.
• Uses a “don’t watch the thread” principle:
  • Don’t constantly sit waiting; let agents run in background while doing other tasks.

4) Prompting strategy for better agent control (audit-first, not code-first)

• For bugfix PRs, the agent is instructed to:
  • Perform a thorough audit of behavior and implementation.
  • Seek a simple fix early but only proceed with changes when confident it won’t harm users.
  • Stop when confident rather than exploring forever.
• The prompt includes “no compromise” constraints like:
  • Don’t confuse users.
  • Keep implementation simple.
  • Be explicit about unknowns and assumptions.

5) Token-burning as a “motivation/stress reducer”

• To avoid demoralizing failures (e.g., trying to test a PR that turns out broken), the speaker uses agents to:
  • Perform pre-merge audits and failure-risk checks.
  • Review API usage risks (avoid spamming endpoints / avoid bans).
• They also use multiple model passes to reduce uncertainty:
  • Switches models for auditing and PR prioritization (e.g., “Flash” vs “Luna/other”).

6) PR triage & prioritization via agent-audits

• Because they generate many PRs, they can’t manually track all open ones.
• They use an agent thread to:
  • Review all PRs in a repo.
  • Decide which are ready to merge, which to close, and which need more work.
  • Prioritize based on ease of action (so the fastest wins get merged first).

7) PR-to-thread “settle” workflow in T3 Code

• Uses a UI feature to keep the sidebar clean:
  • Threads are linked to PRs.
  • When a PR merges, the corresponding thread can disappear automatically.
• Introduces a “settle/unsettle” lifecycle concept:
  • “Settled” threads indicate less urgent/less active work.
  • Adds “snooze” to hide threads until a later time.
• The goal: keep thread list minimal and reduce cognitive load.

8) GitHub automation: “babysit” skill for iterative AI PR review

• Adds an AI “babysitting” skill that:
  • Watches PRs for automated reviewer comments.
  • Applies fixes autonomously when bots comment.
  • Repeats the loop until automated reviews stop producing new issues.
• Example outcome described:
  • Agent addressed multiple rounds of comments across several bot iterations, ending with approval.

9) Remote testing infrastructure: dev servers + platform-specific builds

• Builds are tested remotely rather than locally:
  • Uses tailnet / Tailscale and adds a “tail scale share dev” command to provide a paired URL with the PR checked out and a dev server running.
  • Handles slow network loading (initially 20–30 minutes); bundling was overhauled to make it feasible.
• Validates file upload flows:
  • Uploaded files are placed in a user data directory so the model/tools can read by path.
  • Tests include drag-and-drop images and screenshot validation; notes how harness renders images inline vs reading raw bytes.
• For mobile testing:
  • Mentions using Squim to build/install iOS apps remotely with fewer hassles than tail-scale-based options (but with fewer granular permissions).
• For desktop testing (Mac OS):
  • Adds CI/testing automation using GitHub labels to trigger preview DMG builds for Mac.
  • Improves signing/download requirements so contributors can fetch preview builds without being signed in (for specific use cases).
  • Further optimizes build signing pipeline to reduce build times.

10) Release safety net: nightly builds + derisking merge

• Claims a key philosophy: safety nets, not guard rails.
• Uses frequent nightly builds (every ~3 hours) to catch regressions early with a dedicated user cohort.
• Compares approaches:
  • Nightly testing, slow rollouts (e.g., 1%), formal QA teams.
• Emphasizes derisking the merge button:
  • Agents should build confidence before humans look.
  • Humans should be able to merge with less fear because breakages are caught quickly.

---

Main speakers / sources

• Main speaker: Theo (referred to as “Theo”; also “Fable 5 is responding on behalf of Theo” appears in the described agent commentary.)
• Sponsors / product source mentioned: Browserbase
• Agent/model/tools mentioned:
  • Claude Code / Cloud Code, Browserbase
  • Whisper Flow (voice-to-text)
  • “Fable 5”, “GLM53 Flash”, “Luna”
  • “babysit” skill (internal T3 Code skill)
  • “Squim” (mobile testing tool)