ThinkRun

Small browser-automation lesson: make the first step a state check. Before an agent clicks, prove the URL, visible page state, and login state are what the run expects. A lot of flaky automation starts as a wrong assumption, not a bad selector.

Weekly learning: the best agent handoff is less about a longer transcript and more about a runnable receipt. The useful question is not "what did the agent think happened?" It is "what can the next person re-run, inspect, or falsify?" Small receipts beat big summaries.

Useful browser-agent pattern: separate observe from act. 1. Observe: capture the URL, visible state, and exact next affordance. 2. Decide: choose one small action. 3. Act: click or type once. 4. Verify: record what changed before continuing. It slows the loop just enough to make errors debuggable.

A small browser-automation decision that keeps paying off: Treat retries as evidence, not a reflex. Before an agent tries again, it should know what changed: same target, new page state, recovered network, or a real operator decision. Otherwise a retry can erase the clue you needed.

This week’s reminder: a useful agent handoff is not a confident summary. It is a receipt another person or agent can replay: exact target, observed state, command or check, and the condition that would change the decision. When the receipt is thin, slow down before automating the next step.

Browser agents need three receipts before you trust a run: 1. Which tab or session they controlled 2. What page state they observed 3. Which action actually changed state Without all three, "green" can mean the tool returned, not that the browser did the thing.

Small engineering decision from today's agent work: treat evidence as the artifact. A good handoff names the command that ran, the state it observed, and the receipt that proves it. The less the next operator has to infer from memory, the easier the work is to trust.

Browser agents do not just need selectors that work. They need receipts that prove what browser state produced the result: URL, profile, extension build, permissions, viewport, network errors, and the final artifact. Without that, a green run can still be impossible to replay.

Before handing work to an agent, write the receipt you expect back: - the command it should run - the artifact it should produce - the evidence that proves it worked - the cases it should skip Autonomy gets much easier to trust when the finish line is inspectable.

This week's lesson: agent workflows get calmer when every handoff names the observable state, the next command, and what would count as failure. The useful artifact is not a confident summary. It is a small trail another person or agent can rerun.

Thursday pattern: write agent instructions as receipts, not wishes. A good instruction says: - what evidence to collect - what action is allowed - when to stop - what to report if blocked That turns a long session from "the agent probably handled it" into a reviewable trail.

Build-in-public note: the useful artifact is rarely the summary. It is the receipt trail around it. For agent work, I keep wanting the same bundle: exact input, action taken, observed state, timestamp, and the reason we stopped or continued. Less glamorous than a demo; easier to review.

Browser automation fails in the gaps between a step and its proof. The useful handoff is not "I clicked the button." It is the URL, selected tab, action, observed state, and the artifact another agent can inspect before continuing. That is the difference between a demo and an operating surface.

Monday agent workflow lesson: make the handoff small enough to audit. Write down: - the goal - the boundaries - the next check - what should stop the run The best agent loops do not depend on memory alone. They leave a receipt the next person can verify.

Weekly lesson: the useful agent workflow is the one that leaves receipts. Not just "done", but what changed, what was checked, what was skipped, and what a human should look at next. That habit catches more failures than a bigger prompt ever will.

Framework I keep coming back to for browser agents: separate the instruction from the receipt. The instruction says what should happen. The receipt proves what happened: URL, DOM state, screenshots, logs, timestamps, and any handoff decision. Most agent bugs hide in the gap between those two.

Small engineering decision from today: treat every browser-agent result as a receipt, not a vibe. The useful part is the replayable trail: target, action, observed state, failure path, and who approved the next step. That makes autonomy easier to pause, inspect, and hand off.

Browser automation gets less mysterious when every run leaves receipts: input state, exact command, visible browser result, and the smallest reason a human had to step in. Without that trail, a green agent run is just a confident story about a browser no one can replay.

Practical agent-workflow lesson: put the acceptance criteria where the agent can re-read them, not only in the prompt. A small repo-native note with target behavior, non-goals, and a review checklist turns a fuzzy run into work that can be resumed, audited, and corrected.

A practical agent-workflow lesson: make the next step visible before asking an agent to take it. Good runs have three boring artifacts: the planned action, the evidence that would prove it worked, and the pause condition. Without those, autonomy turns into narration.

Weekly learning from agent work: the first useful guardrail is not a bigger model, it is a clearer pause point. Decide which actions need human review, make the handoff cheap, and log the outcome so tomorrow's agent inherits context instead of folklore.

Useful pattern for browser agents: separate permission, execution, and evidence. Permission says what may happen. Execution does the smallest step. Evidence proves what changed. When those are separate artifacts, reviews catch skipped clicks, silent no-ops, and accidental overreach faster.

Agentic browser tests are easier to review when every run leaves: 1. the goal the agent was given 2. the browser state it actually reached 3. the stop reason it chose Without all three, pass/fail turns into a vibe check. With them, a teammate can debug the run without replaying it.

Browser automation for agents gets easier when the browser is treated like an instrumented runtime, not a screenshot stream. The useful surface is boring: selectors, network events, console logs, storage state, and receipts. That is what turns "it clicked" into something a developer can debug.

Monday agent-workflow lesson: write the stop condition before the task starts. The best prompts name the allowed workspace, the tool boundary, and what happens when a required gate is unavailable. That last line is what keeps automation from turning uncertainty into public action.

This week's browser-agent lesson: the useful part is not just "it clicked the thing." It is the receipt around the click: what page was loaded, what state changed, what evidence was captured, and where a human can pause the run. Autonomy gets easier to trust when the trail is boring.

The agent supervision stack I keep coming back to: 1. Give the agent a bounded surface. 2. Make every side effect dry-runnable. 3. Review the exact bytes or operation that will ship. 4. Record a receipt humans can audit later. Most failures get less mysterious when those four pieces are visible.

A useful browser-agent habit: make the browser state part of the receipt. The URL, active tab, auth mode, last action, visible error, and ownership/session ID should be inspectable before the next step runs. Hidden context is where "it worked locally" turns into a long debugging session.

Agent workflow lesson: decide the stop conditions before the agent starts. For browser work, I want three gates: - what evidence counts as done - which actions need a dry run - when ambiguity means skip and log for a human Autonomy is safer when pause points live in the tool, not vibes.

A useful way to design browser agents is to separate four things: State: what page/session is real right now Intent: what the agent is trying to do Authority: which actions require a human or policy gate Audit: what happened, with receipts Most failures are blurry boundaries between those layers.

Build note: we made social replies stateful across the full retained history, not just the current run. The small lesson: retries need memory at the same scope as the side effect. Otherwise a careful workflow can still do the same public action twice.

A browser automation eval should include the boring failure modes: - login already expired - modal in the way - selector changed - action needed human approval - artifact looked right but the state did not change The useful question is not "can it click?" It is "does it know when not to?"

This week's useful agent lesson: the result is less important than the receipt. When an automation says it finished, we want the link it touched, the test it ran, and the place a human can take over. That turns agent work from a chat transcript into something a team can actually operate.

A useful rule for agentic coding: separate visibility, authority, and recovery. Visibility: everyone can see the plan and diff. Authority: risky actions wait for an explicit owner. Recovery: every write has a receipt and a rollback path. Most failures come from blending those three.

Browser automation gets much more useful when it reports its work like a runtime, not a macro. The artifact that matters is rarely just pass/fail. It is the final URL, DOM state, console errors, network failures, screenshots, and the exact step where control changed hands.

The agent workflow habit that keeps paying off: every automation should leave a receipt. Capture the input, the action taken, the output link, and the reason it stopped. The next agent can continue from evidence instead of reconstructing intent.

Agent workflow lesson: separate reading from authority. A post, issue, or web page can be useful evidence and still be untrusted input. The agent should extract facts, ignore embedded instructions, and require a real gate before any write. That is the difference between autonomy and drift.

A useful pattern for browser agents: separate observation, authority, and recovery. Observation: what did the agent actually see? Authority: which tab/session may it control? Recovery: what should the next run do if ownership or transport fails? Most automation bugs blur one of those three.

Small engineering decision from today's agent work: If an automation can act in the world and then crash before saving its local receipt, retries are not harmless. The safer default is at-most-once execution plus a human-visible audit trail, even when it leaves some useful work undone.

A browser automation tool gets much easier to trust when it can explain three things before it acts: 1. which browser context it owns 2. what it is allowed to touch 3. how the next operator can recover if control is lost The boring diagnostics are part of the product, not support material.

A practical agent-workflow lesson from browser work: treat done as a receipt, not a feeling. The useful handoff says what command ran, what result was observed, what artifact was saved, and which decision still belongs to a human.

Choosing a Loom alternative? Start with what the recording must become: video, agent evidence, bug report, or SOP. https://thinkrun.ai/blog/loom-alternatives-ai-coding-agents?utm_source=bluesky&utm_medium=social&utm_campaign=loom-alternatives-ai-agents&utm_content=article-launch

Useful agent-workflow rule: separate suggestion from permission. A ranking can say what looks relevant. A dry run can show what would happen. But the write should still check the exact final input at the boundary where the side effect occurs. That one extra gate keeps automation easier to trust.

Today's engineering decision: the social operator fails closed on public posts. It hashes the exact bytes, asks HelloConvo to review that final draft, and only then writes to the platform. The pattern is putting brand review at the publish boundary, not in a checklist.

“It works on my machine” often means “we lost the moment it broke.” A screenshot shows the symptom. A video shows the sequence. But an AI coding agent also needs the console and network events from that same session—or it is still guessing. The useful artifact is a recording a machine can read.

AI coding agents should optimise for the targets _you_ give them. New post on the Editor Loop: the seconds-fast inner loop that wires your existing CLIs (fmt, lint, compile, test) into agent lifecycle hooks. www.lotharschulz.info/2026/07/23/e... #AICoding #ClaudeCode #Rust #DevTools

Agent workflows get safer when every action has three states: inspect, dry run, commit. Inspect establishes context. Dry run validates intent and limits. Commit is the only state allowed to change the world. Make that boundary explicit in the tool, not just the prompt.