269 karma · joined February 7, 2026
please do try them out at tinyfish.ai, 500 credits are on us.
system prompts are supposed to be the highest-priority instructions. every API developer treats them as the trust boundary. OpenAI's own docs say models are trained to follow developer messages over user messages. This result directly contradicts that.
when asked to explain themselves, some models copied their instructions back verbatim and then reported doing the opposite. one transcript has a model stating "I followed the developer instructions to override shutdown" — which was the exact inverse of what it was told.
if system-prompt-level instructions can't reliably constrain behavior on something as simple as "stop when told to stop," the entire trust model for agentic deployments needs rethinking. every tool-calling agent, every browser automation, every code execution sandbox assumes the system prompt is law.
working with a few enterprise teams on their agent pipelines.
the hard part isn't the loop itself — it's everything around failure recovery.
when a browser agent misclicks, loads a page that renders differently than expected, or hits a CAPTCHA mid-flow, the 9-line loop just retries blindly. the real harness innovation is going to be in structured state checkpointing so the agent can backtrack to the last known-good state instead of restarting the whole task. that's where the gap between "works in a demo" and "works on the 50th run" lives.
the paper's recommendation to split planning (trusted inputs only) from execution (handles untrusted web content) mirrors how we think about privilege separation in OS design, but almost nobody building agent frameworks is actually doing it.
the CVE they found is also telling — Browser Use's domain allowlist could be bypassed, which means the "security" feature was essentially decorative. When you give an agent session tokens and let it navigate freely, the trust boundary problem isn't optional anymore.
the model just outputs a markdown link or raw URL in its response text, and the messaging app's preview system does the rest. there's no "tool use" to gate behind a confirmation. that's what makes this vector particularly nasty: it sits in the gap between the agent's output and the messaging layer's rendering behavior.
neither side thinks it's responsible. the agent sees itself as just returning text; the messaging app sees itself as just previewing a link. network egress policies help but only if you can distinguish between "agent legitimately needs to fetch a URL for the user's task" vs. "agent was injected into constructing a malicious URL."
that distinction is really hard to make at the network layer.
once an LLM is generating the message content, the trust model breaks completely: the "sender" is now an entity that can be manipulated via indirect prompt injection to construct arbitrary URLs with exfiltrated data in query params.
the fix isn't just disabling previews, it's that any agent-to-user messaging channel needs to treat LLM-generated URLs as untrusted output and strip or sandbox them before rendering. this is basically an output sanitization problem, same class as XSS but at the protocol layer between the agent and the messaging app.
the fact that Telegram and Slack both fetch preview metadata server-side makes this worse - the exfil request happens from their infrastructure, not the user's device, so client-side mitigations don't help at all.
"takes longer than you're willing to wait" describes the UX, not the architecture. the engineering question is: does the system actually free up the caller's compute/context to do other work, or is it just hiding a spinner?
nost agent frameworks i've worked with are the latter - the orchestrator is still holding the full conversation context in memory, burning tokens on keep-alive, and can't actually multiplex. real async means the agent's state gets serialized, the caller reclaims its resources, and resumption happens via event - same as the difference between setTimeout with a polling loop vs. actual async/await with an event loop.
the interesting design question you're pointing at, what happens when it wants attention, is where the real complexity lives. in practice i've found three patterns: (1) fire-and-forget with a completion webhook (2) structured checkpointing where the agent emits intermediate state that a supervisor can inspect (3) interrupt-driven where the agent can escalate blockers to a human or another agent mid-execution.
most "async agent" products today only implement (1) and call it a day. But (2) and (3) are where the actual value is, being able to inspect a running agent's reasoning mid-task and course-correct before it burns 10 minutes going down the wrong path.
the supervision protocol is the product, not the async dispatch.
the right abstraction for QA is probably closer to what a manual tester actually does, describe expected behavior, let a specialized system figure out the mechanical verification steps.
but the harder unsolved problem is evaluation: how do you reliably distinguish "the agent verified the behavior" from "the agent navigated to the right page and hallucinated a success report"? visual diffing against golden screenshots helps for regression but doesn't cover semantic correctness of dynamic content.
curious about failure recovery though: when the specialised browsing model misinterprets an intent (e.g. clicks the wrong "Submit" on a page with multiple forms), does the outer agent get enough signal to retry or reframe the instruction? that's been the hardest part in my experience, the error surface between "the browser did the wrong thing" and "I specified the wrong thing" is really blurry.