<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: webpolis</title><link>https://news.ycombinator.com/user?id=webpolis</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 03 Jul 2026 08:04:59 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=webpolis" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by webpolis in "Show HN: Cloud VMs with a Built-In REST API for AI Agents"]]></title><description><![CDATA[
<p>Loop detection is the harder problem and almost nobody solves it well at the infra layer. The pattern you're describing — write, fail, "fix," regress — is fundamentally a semantic loop, not a mechanical one. You can't catch it by diffing outputs or counting retries because each iteration looks superficially different. The agent <i>thinks</i> it's making progress.<p>What actually works in my experience: budget the agent a rolling token window per subtask, not per session. If it burns 40% of its context on a single function without a passing test, force an early return with the error context and let the orchestrator decide whether to retry with a different prompt or bail. Putting that logic in the VM host is tempting but wrong — the host doesn't have the semantic context to know "stuck" from "legitimately hard." That belongs in the agent framework or a thin supervisor shim between the framework and the execution environment.</p>
]]></description><pubDate>Thu, 12 Mar 2026 12:04:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=47349442</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=47349442</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47349442</guid></item><item><title><![CDATA[New comment by webpolis in "I'm going to build my own OpenClaw, with blackjack and bun"]]></title><description><![CDATA[
<p>Browser plugins have a security problem that's easy to miss: the agent runs inside your existing browser profile. That means it has access to your active sessions, stored credentials, autofill data — everything you're already logged into. A sandboxed machine is actually the safer primitive for untrusted agent tasks, not the more paranoid one. I work on Cyqle (<a href="https://cyqle.in" rel="nofollow">https://cyqle.in</a>), which uses ephemeral sessions with per-session AES keys destroyed on close, because you want agents in a cryptographically isolated context — not loose inside your personal browser where one confused-deputy mistake can reach your bank session.</p>
]]></description><pubDate>Wed, 11 Mar 2026 16:35:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=47337799</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=47337799</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47337799</guid></item><item><title><![CDATA[New comment by webpolis in "Show HN: Time Machine – Debug AI Agents by Forking and Replaying from Any Step"]]></title><description><![CDATA[
<p>The hard part here isn't checkpointing the agent's conversation state — that's just a list. It's checkpointing the <i>world</i> state. If step 5 wrote rows to Postgres and step 7 called a third-party API, forking from step 6 means you need the DB at its post-step-5 snapshot and some way to mock or replay the external call. Without that, you're replaying agent logic against a world that's already diverged. We ran into this enough building agent sandboxing at Cyqle (<a href="https://cyqle.in" rel="nofollow">https://cyqle.in</a>) — our approach is snapshotting the entire ephemeral environment at each checkpoint so the fork includes filesystem, DB state, everything. Curious how Time Machine handles external side effects that can't be rolled back.</p>
]]></description><pubDate>Wed, 11 Mar 2026 14:03:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=47335716</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=47335716</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47335716</guid></item><item><title><![CDATA[New comment by webpolis in "Show HN: Polpo – Build zero-human companies. Open source"]]></title><description><![CDATA[
<p>The keychain-per-agent model is the right instinct, but the threat model gets complicated fast. When five agents share a keychain process, a prompt injection in agent A can exfiltrate credentials for agents B–E — one bad LLM output becomes a full company compromise.<p>The safer architecture is per-session credential scoping: each agent gets credentials minted for that specific task, revoked on completion. That's what we built Cyqle (<a href="https://cyqle.in" rel="nofollow">https://cyqle.in</a>) around — ephemeral sessions where the encryption key is destroyed on close, so if an agent misbehaves, the blast radius is bounded to that session.<p>The keychain needs the same isolation principle, but applied at the task boundary, not the agent boundary.</p>
]]></description><pubDate>Tue, 10 Mar 2026 17:32:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=47326321</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=47326321</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47326321</guid></item><item><title><![CDATA[Show HN: Cyqle – Multiplayer cloud desktops with AI agent sandboxing]]></title><description><![CDATA[
<p>Hey HN,<p>I've been building Cyqle for a while — it's a shared cloud desktop you open in a browser tab and invite people into. Everyone gets their own cursor and keyboard. Think Google Docs, but for an entire Linux machine.<p>The use cases that surprised me most once people started using it:<p>- AI agent sandboxing — spin up a disposable desktop, hand it to an agent, let it browse/run/execute freely, close it when done. Zero risk to anything local. The filesystem is encrypted with a session-unique key; when the session closes, the key is destroyed. The data is cryptographically gone, not just deleted.<p>- Pair programming without the "can you see my screen?" dance — you're both actually in the same environment, not just watching each other.<p>- Reproducing bugs — "here's the link, you're already inside the same exact environment"<p>We also just shipped a ready-to-run Picoclaw snapshot — a lighter, less resource-intensive build of OpenClaw with a custom wizard we developed so you can get up and running in a few clicks, no config archaeology required.<p>Sessions are ephemeral by default. Persistent mode and snapshots available if you need state. Full root, install anything.<p>Free tier has no credit card. Would love feedback from people building AI workflows — the sandboxing side is where I think there's real untapped potential.</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=47316272">https://news.ycombinator.com/item?id=47316272</a></p>
<p>Points: 1</p>
<p># Comments: 0</p>
]]></description><pubDate>Mon, 09 Mar 2026 22:05:49 +0000</pubDate><link>https://cyqle.in/</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=47316272</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47316272</guid></item><item><title><![CDATA[New comment by webpolis in "Agent Safehouse – macOS-native sandboxing for local agents"]]></title><description><![CDATA[
<p>The macOS sandbox approach is clever, but there's an interesting philosophical split here: sandboxing constrains a local agent, whereas running agents in ephemeral cloud desktops removes the local risk surface entirely.<p>We built Cyqle (<a href="https://cyqle.in" rel="nofollow">https://cyqle.in</a>) partly around this idea — each session is a full Linux desktop that's cryptographically wiped on close (AES-256 key destroyed, data unrecoverable). Agents can do whatever they want inside, and the blast radius is zero by design. No residual state, no host OS exposure.<p>The tradeoff is latency and connectivity requirements. For teams already doing cloud-based dev work, it's a natural fit. For local-first workflows where you need offline capability or sub-50ms responsiveness, something like Agent Safehouse makes more sense.<p>Both approaches are worth having — the threat model differs depending on whether you're more worried about data exfiltration or local system compromise.</p>
]]></description><pubDate>Mon, 09 Mar 2026 21:51:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=47316066</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=47316066</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47316066</guid></item><item><title><![CDATA[New comment by webpolis in "LLM prompts as versioned, composable software artifacts"]]></title><description><![CDATA[
<p>As I started building agentic workflows, I found myself frequently creating, improving, and tweaking prompts by editing hardcoded strings and managing text files. I realized this process lacked the crucial software engineering principles that make any project more robust and reliable: versioning, modularity, maintenance, and testing. One of the most important parts of AI agent development is the system prompt, as the success of the workflow's execution depends on it. So, why was I handling this critical step with such a rudimentary approach?
With that in mind, I designed a framework that helps AI engineers build an agent's mind in a composable, shareable, and consistent way. The ultimate goal is to build a public repository for sharing prompt components that anyone can use to shape intelligence.</p>
]]></description><pubDate>Tue, 12 Aug 2025 02:00:28 +0000</pubDate><link>https://news.ycombinator.com/item?id=44871531</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=44871531</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44871531</guid></item><item><title><![CDATA[LLM prompts as versioned, composable software artifacts]]></title><description><![CDATA[
<p>Article URL: <a href="https://github.com/cyqlelabs/pal">https://github.com/cyqlelabs/pal</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=44871530">https://news.ycombinator.com/item?id=44871530</a></p>
<p>Points: 3</p>
<p># Comments: 1</p>
]]></description><pubDate>Tue, 12 Aug 2025 02:00:28 +0000</pubDate><link>https://github.com/cyqlelabs/pal</link><dc:creator>webpolis</dc:creator><comments>https://news.ycombinator.com/item?id=44871530</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44871530</guid></item></channel></rss>