h4cker

Inspiration

I built h4cker because I wanted to put the Flue Agent framework into practice through a complete, production-ready product—not another isolated chatbot demo. Flue is built on Pi Agent, which made it especially interesting to me as a foundation for building a persistent Agent with tools, memory, workflows, and long-running state. Hacker News was a natural environment for this experiment. It contains valuable technical stories, original sources, and thoughtful discussions, but keeping up with everything takes time. Traditional HN readers make browsing easier, yet users still have to manually decide what matters, research unfamiliar topics, remember what they have read, and return for future updates. I wanted to explore what Hacker News would look like if an Agent could participate throughout that entire reading process.

What it does

h4cker is an Agent-powered Hacker News reader that turns browsing into a personalized research and discovery workflow. Users can still browse stories and discussions normally, but h4cker adds several Agent capabilities: A persistent Flue Agent that can summarize stories, explain technical concepts, compare viewpoints, analyze discussions, and research original sources. First Brief, which creates a personalized starting brief based on the user’s interests and initial context. HN Scout, which searches for and evaluates relevant stories around a topic. Agent Digest, which prepares scheduled personalized digests and can deliver them by email. Semantic memory that remembers explicit interests and useful feedback across sessions. Recommendation feedback controls so users can influence future results. Memory and preference controls that allow users to inspect, revise, or remove what the Agent remembers. Reusable research actions, specialized skills, and bounded read-only subagents for source research, discussion analysis, and recommendation review. The goal is not simply to generate summaries. h4cker supports a complete loop: Discover → Read → Research → Remember → Personalize → Deliver

How I built it

h4cker is built as a Cloudflare-native application with separate product and Agent runtime responsibilities. The web application uses TanStack Start with server-side rendering on Cloudflare Workers. A Product API Worker handles authentication, Hacker News data, user preferences, feedback, memory controls, digest history, and delivery records. A separate Agent Worker runs the Flue Runtime. It hosts the persistent h4cker Agent, Flue Workflows, run streams, typed tools, skills, and bounded subagents. The main workflows are: First Brief for personalized onboarding and initial recommendations. HN Scout for topic-focused discovery. Agent Digest for scheduled personalized updates. Research Workflow as a reusable typed action for deeper investigation. Cloudflare D1 is the canonical store for product data, while Flue Durable Objects own Agent runtime state, conversations, workflows, and run streams. This separation lets the Product API remain stable while Flue manages stateful Agent execution. The project also uses Cloudflare AI Gateway for model access, Cloudflare Email for digest delivery, and Browser Rendering as a bounded fallback when a source requires additional retrieval. Shared typed contracts connect the web application, Product API, and Agent runtime. Agent tools execute through the same application-level operations used by the product rather than creating a second implementation of the business logic.

Challenges I ran into

The hardest part was not connecting a model to Hacker News. It was deciding which parts of the system the Agent should own. Product concepts such as entitlements, feedback, delivery channels, digest history, and privacy rules need deterministic application logic. Conversations, tool selection, workflow execution, and runtime events belong to Flue. Keeping that boundary explicit prevented the Agent runtime from becoming a second backend. Migrating an existing application into Flue introduced another challenge. For a while, the old compatibility routes and the new Flue routes existed in the same Hono application. I had to migrate callers carefully, verify the runtime event model, and remove obsolete paths without breaking the product APIs. Memory also required more than storing conversation history. I needed to distinguish explicit user preferences from temporary context, invalidate recommendations when preferences changed, and make memory visible and reversible. Private work context is intentionally excluded from persistent memory and telemetry. Scheduled workflows created additional concerns around idempotency, retries, run identity, delivery state, and replay behavior. A digest should not be delivered twice simply because a workflow is retried. Finally, Agent output quality cannot be judged only by whether a demo looks convincing. I added deterministic tests and an HTTP-based evaluation harness to evaluate tool use, workflow behavior, and output quality more systematically.

Accomplishments that I’m proud of

I am proud that h4cker became a real, deployed Agent product instead of stopping at a framework experiment. The Agent can maintain conversations, invoke typed product tools, execute durable workflows, perform bounded research, remember user preferences, respond to feedback, and deliver scheduled results. I am also proud of the architectural boundary between the Product API and the Flue Runtime. Flue owns Agent execution, while the application continues to own product policy and canonical records. This makes the system easier to reason about, operate, and extend. The complete project is source-available, so other developers can inspect how the Agent, workflows, memory, tools, skills, subagents, delivery system, and Cloudflare infrastructure fit together.

What I learned

Putting Flue into practice showed me that an Agent-native product is not defined by how many tools or prompts it has. The important questions are: Who owns each piece of state? Which decisions must remain deterministic? What can the Agent decide autonomously? How can users understand and reverse remembered preferences? What happens when a workflow is retried or interrupted? How can output quality be evaluated beyond a successful demo? I also found that persistent Agents become much more useful when conversations, workflows, memory, feedback, and delivery are treated as one product system rather than separate AI features. Flue provided the runtime primitives, while Hacker News provided a focused but realistic environment for testing the complete Agent lifecycle.

What’s next for h4cker

The next step is to improve h4cker based on real usage rather than adding capabilities only because they are technically possible. I plan to refine personalized discovery and digests, make recommendation reasoning and memory behavior more transparent, improve the onboarding experience, and continue strengthening evaluation and observability. I also want to keep h4cker useful as a practical reference for developers interested in building persistent Agents with Flue, Pi Agent, Cloudflare Workers, Durable Objects, typed tools, workflows, memory, and controlled subagents. Live product: https://h4cker.app Source code: https://github.com/Go7hic/h4cker

Built With

• cloudflare
• d1
• flue
• hono
• react
• tanstack