Data-driven GEO and marketing agent platform
Show HN: Data-driven GEO and marketing agent platform
AthleteData
Im a triathlete and the data for my training lives in 6 apps: Garmin, Strava, WHOOP, Intervals.icu, Wahoo, Withings, Apple Health, sometimes Hevy. Every morning Id eyeball a few of them and make a call on whether to do the planned session. For the past month I have been building a thing that does this for me, and got it to the point where I use it myself every day. It OAuths into whatever platforms you connect, reconciles the activities (tbh harder than it sounds — same ride shows up in Strava, Garmin, and Wahoo with different timestamps and rounding), computes daily load and readiness, and proactively messages you over Telegram or Whatsapp when something matters. Stack is straightforward: Typescript all the way, Postgres, an agent loop running on Claude (via Bedrock) with tool access to all your data + my computed metrics: zones, CTL/ATL/TSB, power/pace curves, anomaly detection on HRV and RHR, etc Two things that were harder than expected: 1. Garmins API only exposes the last 90 days. So for anyone with Garmin as their primary device, you have to backfill from Strava and stitch the two together. Strava has full history but misses some fields (e.g. HR-based TSS only — no power). Wahoo and intervals.icu fill different gaps. The dedup pipeline is ugly and I'd welcome feedback from anyone who has solved this better. 2. Deciding when to message vs. stay silent is entirely a product problem. Too chatty -> muted. Too quiet -> feels dead. One honest caveat though: no RCT data, and Id be skeptical of anyone who claims they have it for AI coaching at this stage. I am at ~50 paying users, I personally reach out to every user to build the next iterations of the product based on feedback. Already got testimonials from Ironman world championship finishers and other pro athletes. Theres also a $9/mo MCP tier for people who would rather pipe their data into their own Claude/ChatGPT. Happy to go deep on any topic! e.g. the tool-calling architecture, or the cost-per-user question (running an agent on every athlete daily is not free, and the margins here are worth discussing).
Physics-accurate 3D assets for robotics simulations from any input
In the past 4 years, we developed a platform generating 3D visuals and deploying AR Try-on experiences into large footwear and retail companies. We focused on high-fidelity meshes and textures since the point was giving shoppers a realistic visual. Then robotics companies started to approach us and they asked for thousands of 3D assets that they can use in creating different simulation environments. This is crucial for them so they can achieve better sim-to-real transfer with domain randomization (train a humanoid in a million different kitchens so a real one is not a surprise when it is deployed in the real world). However, we realized nice geometry and pretty textures are not enough for sim engines as they lack physics properties. So we developed a new pipeline creating SimReady assets in OpenUSD and MJCF that plug directly into Isaac Sim and MuJoCo. - Mass: volume from the mesh, density from material classification by a vision-language model (approach adapted from NeRF2Physics), multiplied together. - Center of mass, static/dynamic friction coefficients and restitution from the same material classification and estimation priors. - Collision meshes via CoACD; adaptive hull count is in progress. - Geometry and texture optimization, plus file format conversions. - We are currently focused on physics property estimation for props. Next step: articulated objects It comes with free credits on easy Google sign-up so you can give it a test. No credit cards required. Still early. All we'd ask is honest feedback. What works, what doesn't, what you wish it did differently. That's worth more to us than anything right now.
CatchAll
Hey HN, Artem and Maksym from NewsCatcher here. Some of you know us as we started six years ago as two freshly graduated economics students who decided to build the best news API product. We started NewsCatcher thinking the market for news APIs was so big that we could build a self-serve platform and get millions of $29 users. Obviously, it was a wrong assumption. We pivoted to serve enterprises and had success with it. But we are hackers at heart, and we want to serve hackers. We haven't used our Launch HN yet, so consider this our smoke test. We're looking for feedback and power users rather than revenue. So, happy to provide enough credits for any HN user who finds CatchAll useful. CatchAll is built for one thing: retrieving every matching event from the web. The use cases that fit it are ones where missing events have real consequences — funding and M&A monitoring, regulatory and compliance feeds (FDA approvals, SEC filings, policy changes), cybersecurity incident tracking, supply chain signals. If your pipeline consumes structured records and the answer to your query is "find all of them," that's where it works. It's not the right tool for small, bounded queries that return 5 high-precision results. The 15-minute job time is a direct consequence of the pipeline depth: analyze, fetch, cluster, validate, extract, deduplicate. You're not getting a ranked list of links; you're getting a verified record set. Our latest benchmark run: https://newscatcherapi.com/blog-posts/web-search-api-benchma...
A visual CI/CD system
Over a year ago I started Actionforge, a managed/self-managed visual CI/CD platform. Just for fun, because I like building and experimenting with dev tools. Back then I thought the user would be a human with a keyboard and a mouse. These days I rarely write pipelines. I mostly write specs, an agent dumps 500 lines of YAML, Python and a Makefile then I get my artifacts. The amount is overwhelming and a liability, and I stop trusting what I just merged. So I pivoted my CI/CD project toward more visualization, analytics and data aggregation, so engineers can see what agents and the pipeline produced, the flow, steps, data. Where it fails. With that I have a better mental model instead of a blob of code. The goal is better observability, and pipelines that explain their own failures back to the next agent. And also with a personal focus on UX and design. My project supports Perforce P4, Git/GitHub and GitLab, so quite flexible. Would love to hear your impression. I'm also very interested in your CI/CD horror stories, and how you use them these days. Any input is much appreciated! P.S. Code is public and provides GitHub Attestations.
Endo Familiar, an O-cap based JavaScript agent sandbox
Show HN: Endo Familiar, an O-cap based JavaScript agent sandbox
I built a toy that plays grandma's stories when my daughter hugs it
This was a project I built for my daughter's first birthday present. For context, I'm a surgical resident in the UK by background and am currently taking a year out of training to study a masters in computer science. My daughter just turned one. There are two things she really loves: the first is particular soft toy that she just can't live without, and the other is a good story book. Her grandparents live hours away and I didn't want her to forget what they sound like between visits. I wanted her to hear them whenever she missed them. My parents brought my brother and I up with incredible stories and books from all sorts of cultures, many of the stories being passed down from their parents before them. I didn't want my daughter to miss out on that. Finally, I was sick of missing storytime with her when I had to leave for night shifts. I wanted her to hear my voice before she slept every night. For all these reasons, I decided to build Storyfriend. It's her favourite soft toy with a custom made speaker-module inside. I combined my surgical skills with the skills I was learning as a CS student. Along the way I dipped my toes into the world of 3D printing, CAD and electronics design. When she hugs the toy, it plays stories read by her grandparents. She can take the toy with her anywhere and hear the stories anytime she wants - it works offline and has internal storage. It meets my wife's strict no-screen rule (which is getting harder to stick to as the days go by). I've recorded some of the stories that we would read together, so that on nights when I'm working she still has me there to read her a bedtime story. The bit I'm most pleased with: grandparents don't need an app. They just call a phone number. The audio routes through my server and pushes to the toy over WiFi. My own 86-year old grandmother in a rural village in another country can do it by just making a regular call via her landline, as she has done for many years - no help needed, no apps required, no smartphones involved. Hardware is a BLE/wifi module with a MAX98357 chip and custome battery management system, all soldered together, placed in a 3D printed enclosure and placed into a compartment that I stitched into her cuddly toy. Firmware pulls new messages when connected to WiFi and stores them on an SD card. So far I've sold a few hand-made units to parents and grandparents who resonated with the project. Site: https://storyfriend.co.uk Would love feedback on the technical approach, the product itself, or anything else. Happy to answer questions about the build
Atomic
Show HN: Atomic – Local-first, AI-augmented personal knowledge base
I've built a nice home server OS
ohai! I've released Lightwhale 3, which is possibly the easiest way to self-host Docker containers. It's a free, immutable Linux system purpose-built to live-boot straight into a working Docker Engine, thereby shortcutting the need for installation, configuration, and maintenance. Its simple design makes it easy to learn, and its low memory footprint should make it especially attractive during these times of RAMageddon. If this has piqued your interest, do check it out, along with its easy-to-follow Getting Started guide. In any event, have a nice day! =)
Agent MCP Studio
I built a browser-only studio for designing and orchestrating MCP agent systems for development and experimental purposes. The whole stack — tool authoring, multi-agent orchestration, RAG, code execution — runs from a single static HTML file via WebAssembly. No backend. The bet: WASM is a hard sandbox for free. When you generate tools with an LLM (or write them by hand), the studio AST-validates the source, registers it lazily, and JIT-compiles into Pyodide on first call. SQL tools run in DuckDB-WASM in a Web Worker. The built-in RAG uses Xenova/all-MiniLM-L6-v2 via Transformers.js for on-device embeddings. Nothing leaves the browser; close the tab and the stack is gone. The WASM boundary is what makes it safe to execute LLM-generated code locally — no Docker, no per-tenant container, no server. Above the tool layer sits an agentic system with 10 orchestration strategies: - Supervisor (router → 1 expert) - Mixture of Experts (parallel + synthesizer) - Sequential Pipeline - Plan & Execute (planner decomposes, workers execute) - Swarm (peer handoffs) - Debate (contestants + judge) - Reflection (actor + critic loop) - Hierarchical (manager delegates via ask_<persona> tools) - Round-Robin (panel + moderator) - Map-Reduce (splitter → parallel → aggregator) You build a team visually: drag tool chips onto persona nodes on a service graph, pick a strategy, and the topology reshapes to match. Each persona auto-registers as an MCP tool (ask_<name>), plus an agent_chat(query, strategy?) meta tool. A bundled Node bridge speaks stdio to Claude Desktop and WebSocket to your tab — your browser becomes an MCP server. When you're done, Export gives you a real Python MCP server: server.py, agentic.py, tools/*.py, Dockerfile, requirements.txt, .env.example. The exported agentic.py is a faithful Python port of the same orchestration logic running in the browser, so the deployable artifact behaves identically to the prototype. Also shipped: Project Packs. Export the whole project as a single .agentpack.json. Auto-detects required external services (OpenAI, GitHub, Stripe, Anthropic, Slack, Notion, Linear, etc.) by scanning tool source for os.environ.get(...) and cross-referencing against the network allowlist. Recipients get an import wizard that prompts for credentials. Manifests are reviewable, sharable, and never carry secrets. Some things I'm honestly uncertain about: - 10 strategies might be too many. My guess is most users only need Supervisor, Mixture of Experts, and Debate. Open to data on which ones actually pull weight. - Browser cold-starts (Pyodide warm-up on first load) are a real UX hit despite aggressive caching. - bridge.js is the only non-browser piece. A hosted variant is the obvious next step. Built with Pyodide, DuckDB-WASM, Transformers.js, OpenAI Chat Completions (or a local Qwen 1.5 0.5B running in-browser via Transformers for fully offline mode). ~5K lines of HTML/CSS/JS in one file. https://www.agentmcp.studio Genuinely curious whether running this much LLM-generated code in a browser tab feels reasonable to you, or quietly terrifying.
LLMs consume 5.4x less mobile energy than ad-supported web search
The standard AI energy debate compares server-side LLM inference to a server-side Google query. I think this misses most of what actually happens on a mobile device during a real search session. I built a parametric model of the full end-to-end mobile search session: 4G/5G radio energy, SoC rendering cost for a 2.5MB page, programmatic advertising RTB auctions running in the background, and network transmission costs for both sides. Then compared it to an equivalent LLM session. Main finding across 10,000 Monte Carlo draws: on mobile, a standard LLM session uses on average 5.4x less energy than a classic ad-supported web search session. Programmatic advertising alone accounts for up to 41% of device battery drain per session. Caveats I tried to be explicit about: - Advantage disappears on fixed Wi-Fi/fiber - Reverses for reasoning models - Parametric model, not empirical device measurement. Greenspector has offered to run terminal measurements for v2 - Jevons paradox applies SSRN working paper, not peer-reviewed. Methodology and Monte Carlo distributions fully documented in the paper. Happy to defend the assumptions. DOI: 10.2139/ssrn.6287918
Limen
I built and released Limen v0.1.0: https://github.com/thecodearcher/limen Writeup/docs: https://limenauth.dev/blog/introducing-limen It’s inspired by better-auth’s plugin-first DX, but designed for idiomatic Go. The core handles sessions/cookies/security primitives, and auth methods are composed as plugins (credential auth, OAuth providers, and 2FA today). It exposes an http.Handler, so it works with plain net/http and frameworks like Gin/Echo/Chi/Fiber without framework lock-in. This is the first public release. I’d really appreciate feedback.