Каталог продуктов

CA

Capgo

Мгновенные обновления для Capacitor-приложений. Выпускайте исправления за минуты, а не недели. Отправляйте OTA-обновления пользователям без задержек App Store.

KA

Kandelo

Kandelo is an open-source, Wasm-based multi-process kernel that runs POSIX programs in browsers and Node.js. Kandelo is still experimental, but it already runs a substantial range of existing software. Do you have use cases for this? We are trying Kandelo as a new foundation for WordPress Playground which runs server-side WordPress entirely in the browser. Kandelo also looks promising as a sandbox for running agents in the the browser and on the command line. On the side, we've been playing with porting games and desktop environments and even compiling runnable programs within Kandelo. Yet it feels like there are many possibilities we haven't considered. How would you like to use something like this? Demos: Some notes: The demos have been tested in desktop browsers. Unfortunately, YMMV on mobile today. Some of the disk images are large (~50MB) and may take a while to boot initially. Main set, with Shell (bash, vim, nethack, and more), Nginx, PHP, WordPress, and Doom: https://kandelo.dev/20260819-demo/ LÖVE game engine: https://kandelo.dev/20260819-demo-love/ SNKRX running under LÖVE: https://kandelo.dev/20260819-demo-love/?vfs=love-snkrx-abi44... Commander Keen running in DOSBox: https://kandelo.dev/20260819-demo-dos/?demo=keen LXDE desktop PoC: https://kandelo.dev/20260819-demo-lxde/?demo=desktop-lxde Background I wanted an authentic OS-level foundation for running systems software in the browser and started this as a vibe-coded exploration. I figured it would end up being too slow and that we would have to offer many different ways to compromise default POSIX behavior to get anything usable. But after weeks of fighting agents, insisting on genuine POSIX compatibility as the default, I was surprised at how well the system worked without those compromises. Nginx, PHP, Python, Ruby, Redis, and even MariaDB were able to be built using the SDK with minimal hacks. Then we started porting games, having fun, and playing to see how far we could push it. Notes on architecture: There is a central, single-worker kernel, aiming to provide all supportable POSIX syscalls. Each process is a dedicated worker with independent memory. Each process thread is a dedicated worker that shares memory with threads from the same process. Syscalls are done with the process SharedArrayBuffer and the Atomics API. fork() is supported. The system is centered around virtual file system (VFS) images, and the VFS can contain lazy references to programs that may or may not be used. Vim is such a reference in the shell demo. On GitHub: https://github.com/Automattic/kandelo

HY

Hyperprobe

Hi HN, this is Shailendra and Karan here. We are building a fast and safe way for coding agents to debug issues live in production. When prod breaks, it lets Cursor, Claude, and others drop virtual breakpoints or probes safely in your running code, and extract the exact variable values that logs don’t have. All this saves time and effort for engineers who’d otherwise dig through logs and traces or redeploy with console.logs or print statements until they find the root cause. Here is the link to the video that explains this: https://www.youtube.com/watch?v=ivV7I--ta5c Agents write most of our code now. This shrinks the useful context engineers need to debug AI written code, a problem not helped by the limited telemetry added in the same code by AI. So when something breaks in prod, the first instinct for an engineer is to open logs or throw them to your agents. But if the line you are looking for is not there, agents will start guessing the root cause on non-existent data, forcing you to add a log, and redeploy. This analysis-inference loop of agents with existing data does not come cheap, burning a lot of tokens. And the add log, redeploy cycle is so slow and painful that it makes engineers hate on-call. Our approach lets agents capture telemetry on-demand at the exact moment and point of failure, killing the log-redeploy cycle and getting the most accurate RCA while burning fewer tokens. The obvious problem is making it work on a running service. You can't pause a live service the way you'd pause a debugger on your laptop. Getting the value out of a running process safely, without pausing a thread or slowing the host is the challenge.We are making this happen. Before this I ran engineering at a 100 member team. Then Karan and I spent three years on HyperTest which was a testing tool. At HyperTest, we turned production traffic into integration tests using OpenTelemetry. That was production instrumentation too. The hard parts of pulling real runtime state out of a running service without breaking it, were the hard parts we learnt to put together. We learnt some other lessons the hard way too. HyperTest tried to prevent bugs with better tests, and adoption was a fight every time. Calls kept getting cancelled because teams were firefighting production. Testing was hygiene. Broken prod was hair on fire. This made us see where priorities lie. This seeded the idea of building a truly autonomous on-call agent i.e. one that takes an alert, probes, diagnoses and fixes it in a few minutes. But this is how it works as of now: You talk to your coding agent the way you already do. Tell it what's wrong: "checkout returns 200 but some users are seeing their order fail, find out why." It locates the line in your local code, connects to us over MCP, and drops a probe on that line in the running service. The probe is read-only and sits dormant until real traffic hits. When hit, it captures the local variables at every frame of the call stack at that exact moment. It hands them to the agent, which diagnoses with real data. There are two pieces. An SDK that runs inside your service, and an MCP server your coding agent talks to. The SDK is what makes setting probes (virtual breakpoints, log or metric) possible without a redeploy. In Node and Python it hooks in-process. In Java it attaches as a JVM agent, instrumenting at the bytecode level. Either way the service keeps running and serving traffic. Nothing pauses. When your agent wants to look at a line, it calls the MCP server, which tells the SDK to place a probe there. When a request hits the line, the SDK captures what the probe asked for, sanitizes it in-process, and streams it back to the agent via the MCP. This can run inside prod, so a probe can read any value sitting in that variable. We ensure redaction happens in-process, inside your own container's memory. This is before anything goes on the wire. Keys like password, token, authorization, ssn and credit card are redacted by default and you add your own. Also the probes read but never write, and if you want no captured state to ever leave your network you can self host the server, broker, and even the database in your infra. On overhead: when idle, the SDK adds negligible memory and effectively nothing to throughput and response time. Probes only cost anything while actively capturing. Also captures are bounded. A separate monitor watches in real time and pulls every active probe if overhead ever spikes. Every log-and-trace tool hands the agent data that already exists and asks it to reason backward to what probably happened. We think it is more useful to give agents eyes and ears into the running code, so they capture what they need when they need it, right at the point of failure. This seems like the simplest and fastest way to debug prod incidents. We’d love the community to try this in any environment to debug any known or unknown issue by just chatting with your coding agent. And let us know what more features you need to make this a truly autonomous on-call agent Supported platforms: NodeJs, Java, Python.

HT

How to build and self-host a code review agent

Hey HN, I've had a side-project that I've slowly ticked away at over the last year called Tilde. Tilde is a harness SDK platform - I've tried to take the best things of OpenClaw, Hermes & other harnesses and decompose them and make them available as cloud API building blocks. You can use Tilde to create AI agents for your use case, fast and self-host the agent's yourself. The documentation (and attached blog post) leave a lot to be desired in terms of technical documentation but hopefully the attached git repo does a good job of showcasing the API. https://github.com/trytilde/examples

RS

Replicant Space

During Christmas 2025, I found myself burnt out from work. The last few years had been hard, and multiple redundancies saw the company I loved reduce down to just a handful of remaining staff. As a coping mechanism, I kinda disassociated for a while - throwing myself into my personal projects. AI was destroying the passion I had for coding. I tried to find some meaning in development again. After months of throwing myself into creating this game, I slowly fell back in love with coding. I taught myself a bunch of technologies that I was previously unfamiliar - Astro, Flask, Redis, Celery, Just. Anyway, this is Replicant Space. It's free. I love building and playing it. There's a cool story. Aliens are awesome. Feel free to poke the API and take over the galaxy.

FL

Flashpaper

Hi everyone! This is my first HN and I’m very new to the scene. My name is Min from Bangkok. At first, I just want to create a dead man's switch for personal use and for fun. then, I think about information that self destruct like a spy movie. after that, I try to come up with the better version of Privnote or Bitwarden with self-destruct and some kind of censoring or blocking download ability. Somehow, end up with this product. :O Flashpaper is for sending any information that would be burned after reading (with counting down timer like Mission Impossible movie ! or after 24 hrs max if not opened) Encryption happens in browser and because the key stays after # in the link; server never sees the key (Zero-knowledge for web use) and— because I’m a newbie. I don’t want to connect to database because I don’t have the money and I want things light and simple. So, that’s why Flashpaper keeps things in RAM-only, no database. For AI Agent side, Flashpaper provides a REST API and an MCP server so agents can create secret links easily in dead-drop style that can be claimed only once. The second claim would get a 404 which means someone already took it. However, for the agent API flow, the server sees the plaintext for a moment before encrypting, so this flow is not zero-knowledge like the web flow. Overall, I think it work quite well for web use, but for agent API use, I am not sure this is enough security. All the limitations are listed in SECURITY.md. Some feedback would be appreciated. I make it open source with MIT license, with honorware policy for Enterprise use, like self-hosted docker. Here is my repo https://github.com/mmmpym/flashpaper and you can try it here https://flashpaper.app Again ! Please feel free to tell me what I missed. Min

RI

Rise-reforming

Hi HN! This is George, Lucas, and Jona from Rise Reforming (https://www.rise-reforming.com/). We’re developing a process to convert gas produced at landfills, farms, and wastewater plants (“biogas”) into higher value chemicals. Our technology is modular, designed to be deployed and operated on-site. Think of us as a chemical project developer; we sit between biogas producers (suppliers) and chemical end users (customers). We pay biogas producers for their gas and we make money from selling our chemicals. We're starting with dimethyl ether (DME) as our beachhead chemical because of its high-margin use case in the cosmetics industry and ultimately targeting methanol – a versatile and widely used industrial chemical. Being in a two sided market allows us to target two large problems. (1) On the chemical side: The multi-trillion dollar U.S. chemical and fuel industries are vulnerable to geopolitical conflicts and climate-driven natural disasters. The Iran war has caused global methanol prices to skyrocket – even in the U.S., a net exporter of methanol. (https://www.spglobal.com/energy/en/news-research/latest-news... the US). In 2021, Winter Storm Uri wiped out 60% of U.S. organic chemicals production for at least a month (https://www.dallasfed.org/research/swe/2021/swe2102/swe2102c...). The problem? Centralized production and fossil-fuel dependence. The solution isn't unknown; decentralized, fossil-free production could insulate supply chains from these shocks. But distributed green chemical production has yet to become cost-competitive with the status quo. Unlocking it requires the right feedstock paired with the right process and strategy. Also, the chemical industry’s reliance on fossil fuels makes it responsible for 5-6% of global greenhouse gas emissions. About 40% of the industry’s well-to-gate emissions come from just the extraction, processing, and transportation of these fossil fuels (https://rmi.org/resources/chemistry-in-transition-charting-s...). (2) Biogas is an ideal feedstock to address Problem 1. It is decentralized, plentiful, and a large part of it is not properly utilized. Biogas is a mixture of methane (CH4) and carbon dioxide (CO2), produced as a result of anaerobic digestion at landfills, farms, and wastewater plants, and can be used as a raw material in chemical manufacturing. The U.S. produces around 780 billion cubic feet of biogas a year – if we converted all that biogas into methanol, that’s about $20 billion a year. Currently, about 60% of this biogas is either burned for power/heat (low-margin and unreliable) or flared altogether. The rest is used in the highly subsidized renewable natural gas (RNG) market (https://americanbiogascouncil.org/abcs-data-digest-lite-july...). The result: many biogas producers leave substantial revenue on the table and experience huge operational headaches. Our modular technology takes in biogas, electricity, and water as inputs. Co-location with biogas producers allows us to tap into their existing infrastructure and speeds up permitting vs a greenfield project. Our 3 step process is outlined below: Step 1: We clean the biogas of contaminants. That means running the gas over specialized adsorbents that trap any nasty sulfur-containing and silicon-containing compounds we don’t want in our process. Step 2: We reform that biogas into an intermediate gas called syngas through the bi-reforming process, which combines the novel dry methane reforming reaction with the legacy steam methane reforming reaction. Syngas is a versatile combination of H2 and CO and is the building block for many chemicals, allowing us to be a platform company. Step 3: Lastly, we upgrade that syngas into our end chemicals. We do this step using conventional catalysts and operating conditions. The modular approach paired with our patent-pending integrated process makes our solution one of the cheapest ways of making green chemicals. Where are we today? We’ve completed our proof-of-concept in the lab and just broke ground on our pilot plant at a Chicagoland wastewater plant that currently flares all of its biogas. We will convert that wasted biogas into methanol. Estimated commissioning is Q1 2027. We all met at the University of Chicago studying Molecular Engineering and started the company back in June 2024. Rise Reforming’s first iteration came after attending a talk from an Argonne National Laboratory researcher on low-carbon fuels. In that seminar, we heard about a reaction called “dry reforming” wherein one can react CH4 with CO2, effectively eliminating both pollutants and making useful syngas (CO + H2). We realized that this reaction could enable cheaper decarbonization of chemicals than the legacy electrolysis pathway and started to build a technoeconomic analysis. George has a background in energy generation, storage, and carbon capture. He was an early employee at Highland Electric Fleets (now a unicorn) and later worked at Nexamp, GenH, and Mantel Capture – researching various battery chemistries, building a first-of-a-kind (FOAK) modular hydropower system, and helping prove a novel point-source capture prototype. He also conducted battery research at UChicago's Patel Lab and Rowan Group, co-authoring two papers. Lucas led the design, procurement, construction, and operation of Rise Reforming’s bench-scale reforming unit with controls that operated successfully for over 1800+ continuous hours. Prior to Rise, he worked at Avangrid (Iberdrola Group) with the offshore wind project services team and did transmutation research of spent nuclear fuel at Argonne National Laboratory. Jona also studied Molecular Engineering at the University of Chicago. He grew up around the marine industry and brings deep knowledge of the space to the team. While at UChicago, he conducted research in the Patel Lab on batteries and sustainable polymer applications and built novel equipment for the lab, including a high-throughput cyclic voltammetry battery performance testing device. Our advisory board has 220+ combined years in aerosols, permitting/safety, low-carbon fuels, catalysts, scale-up, automated modular chemical plants, and wastewater treatment. Here’s our launch video if you want to put faces to the names: https://youtu.be/Bx_ASPapxlQ?si=PAlqvd1eUhW8kjJm. We’d appreciate any feedback, questions, or advice. Thank you for reading! George, Lucas, and Jona

UN

Unlayer

Hi HN, We’re Adeel and Umair, co-founders of Unlayer (https://unlayer.com/). We let you add content creation to your applications without having to build an entire editor, renderer, template, and export stack yourself. Unlayer lets you create emails, web pages, and documents inside your app, in three different ways: in code, visually, or with AI. Here’s a demo: https://www.youtube.com/watch?v=0HsDtNkdMpM. We started with an embeddable email editor because a lot of products eventually need one: CRMs, marketing tools, customer engagement platforms, marketplaces, internal tools, and vertical SaaS apps all run into this at some point. At first, it sounds like a small feature: "just" add a drag and drop editor. In practice, it turns into a big pain. You end up dealing with email rendering, Outlook quirks, responsive layouts, templates, merge tags, image uploads, exports, permissions, localization, versioning, and a long tail of edge cases that have nothing to do with your core product Over time, we saw the same problem beyond email. Apps also need landing pages, invoices, proposals, reports, contracts, and PDFs. Some of this content is best created visually by end users. Some of it is better generated in code by developers. Increasingly, some of it is also generated by AI agents. Many teams eventually need all three workflows. That is the direction we have been working toward with Unlayer. There are three parts we are showing today: (1) Unlayer Elements. This is our open-source React component library for creating emails, pages, and documents in code (repo: https://github.com/unlayer/elements, more at https://unlayer.com/elements). Instead of hand-writing raw HTML templates, developers can compose content using React components, reuse sections like headers, footers, CTAs, invoice rows, and branded blocks, keep templates in Git, and render them into production output. One newer use case we are seeing is AI-assisted content creation. If an AI agent is asked to create an email, invoice, report, or landing page, the output is usually raw HTML or markdown that becomes hard to maintain. With Elements, the agent can generate structured React components instead. A developer can review the result, refactor it, keep it in Git, and still pass the design into a visual builder later if someone needs to edit it. (2) Visual Builder. This is the drag and drop editor (repo: https://github.com/unlayer/react-email-editor, more at https://unlayer.com/email-builder) that can be embedded inside an app so non-technical users can create or edit content. In the demo, we show the email builder and the AI assistant inside the builder. The goal is not to replace the developer workflow, but to connect it with a visual workflow when marketers, admins, customers, or internal teams need to make changes themselves. (3) Document Builder. This is for structured documents such as proposals, reports, invoices, contracts, and PDFs. We have seen a lot of teams build separate systems for email templates, web pages, and document generation, even though the underlying primitives are similar: layout, content blocks, variables, assets, preview, export, and permissions. More: https://unlayer.com/document-builder The technical challenge is making these workflows share a common foundation. Developers should be able to build templates in code when that makes sense. End users should be able to edit visually when that makes sense. AI agents should be able to generate structured content instead of unmaintainable blobs. The final output should still be usable by the host application. We make money by selling hosted builder, template, export, and platform features to companies embedding this into their products. Elements is open source. The commercial product is the broader hosted platform around builders, collaboration, storage, exports, and production use cases. We were part of W22, so this is a late Launch HN. At the time, Unlayer was an embeddable email editor, and we did not think we had the right broader story for HN yet. Since then, the product has expanded into a more general content creation layer for products, including emails, pages, documents, APIs, open-source developer projects, and AI-assisted workflows. That felt like a better moment to bring it to HN and ask for feedback. We'd really appreciate thoughts from HN. This is one of those areas where a lot of people have strong opinions because they’ve been burned by editors, email HTML, document editing, or “simple” content workflows before. We'd love to hear what resonates, what sounds wrong, and what you think we should be thinking harder about!

LP

Libretto PR agents

Libretto PR agents is a free TypeScript library for maintaining Playwright browser automations. Add one line of code to your existing Playwright scripts and it lets an agent automatically open GitHub PRs fixing the script when it fails. A few months ago we released Libretto, a CLI + coding-agent skill for building deterministic browser automations. The idea was that for many browser workflows, especially repetitive business workflows, you don’t need an AI agent making decisions at runtime. You want deterministic Playwright scripts that are inspectable, faster to run, and much cheaper than repeatedly calling an AI browser agent. That helped us generate Playwright and network-request-based scripts, but websites can often change which breaks deterministic scripts. So maintaining a variety of scripts at scale is a headache. If you already have a bunch of functioning Playwright scripts, the last thing you want is to rewrite everything around a new runtime AI framework like browser-use or stagehand just to make maintenance easier. The Libretto PR Agent pulls your code from GitHub and connects via CDP to the browser session that just failed. It has an exec tool for injecting Playwright and javascript into the page, and once its inspected the failure, it opens a PR to your repo with a proposed code fix. You use it like this: try { await automationLogic(page); } catch (error) { await playwrightDebugger.debugFailure(error, page); throw error; } The agent is completely free and open source, lets you bring your own LLM provider API keys, and works with any browser provider (including self hosted). The source code is here: https://github.com/saffron-health/libretto/tree/main/package... We think this makes browser integrations much easier to maintain, especially for teams that already have Playwright browser automation scripts in production and don’t want a full migration to get AI-assisted debugging and repair. If you’re maintaining browser automations in production, would love to know what your debugging flow is currently and any feedback on this approach.

CO

Coasty

Hey HN, we’re Nitish and Prateek, the founders of Coasty (https://coasty.ai/computer-use). We’re building computer-use agents that can complete workflows inside legacy desktop software and web applications without usable APIs. Developers send Coasty a natural-language task either through our consumer app or through our API, select a machine or browser environment, and any relevant credentials or files. The agent then operates the interface through screenshots, mouse, and keyboard input, verifies the result, and returns a structured run record with screenshots, actions, outputs, and errors. Here is a raw demo of an agent completing a workflow in a legacy application(It’s a mockup): https://drive.google.com/file/d/1ZghU_3vsAYhHVz1bsvE0pkvZYk7... A lot of important software is still difficult to automate. Healthcare teams submit prior authorizations through payer portals, accounting teams enter data into desktop applications, and operations teams move information between internal systems, spreadsheets, and remote desktops. Many of these applications have no API, incomplete APIs, or integrations that take months to build. The usual alternative is RPA, record a sequence of clicks and replay it. That works when the interface and workflow are predictable, but it often breaks when a button moves, a pop-up appears, a page loads slowly, or the application enters an unexpected state. Coasty takes a different approach. The agent observes the current screen, decides what action to take, executes it, and then observes the resulting state before continuing. It does not require DOM access, an accessibility tree, selectors, or an application-specific integration, so the same API can operate browsers, remote desktops, and older Windows applications. A simplified request looks roughly like this: run = coasty.runs.create( environment="vm_123", task=""" Open the patient record in the billing portal. Enter the attached authorization data. Do not submit if the member ID or procedure code does not match. Return the confirmation number. """, files=["authorization.pdf"], approval_required=["final_submission"] ) The response includes the final status, extracted outputs, a replay URL, and a timestamped event log: { "status": "completed", "output": { "confirmation_number": "PA-184392" }, "replay_url": "...", "events": [ { "type": "verification", "field": "member_id", "result": "matched" } ] } The API can also pause a run for human approval, retry from a checkpoint, or return control to the developer when it encounters a condition the workflow did not anticipate. We started working on this last summer, because we saw that models were getting better at vision but kept seeing a gap between computer-use demos and the reliability needed for production workflows. Getting an agent to complete a task once is fairly straightforward. Getting it to repeat that task, recover from unexpected states, avoid silently entering incorrect data, and produce evidence of what it did is much harder. We built several layers around the underlying computer-use model. The system tracks the expected state of the workflow, detects when the application has diverged from that state, and can re-plan instead of continuing blindly. Developers can define invariants such as “the patient name must match the source document” or “never submit without approval,” and the agent checks those conditions during the run. Each run happens in an isolated virtual machine. We expose APIs for provisioning environments, uploading files, starting tasks, streaming events, inserting human approvals, and retrieving the full replay and audit trail. Environments can be kept alive across runs when the application has a long login flow or persistent local state. One problem we are still working through is the tradeoff between speed and reliability. The agent can move faster by taking fewer observations and verification steps, but that becomes risky in workflows involving patient records, payments, or regulatory filings. We currently bias toward slower execution with more checks and let developers configure approval points and verification policies. We are initially working with healthcare operations teams because their workflows combine many of the hardest conditions: payer portals, EHRs, PDFs, spreadsheets, remote desktops, and actions where quiet mistakes are expensive. We also expose the same infrastructure through the developer API for teams building their own agents and vertical automation products. We currently charge based on agent runtime and workflow volume, with separate pricing for dedicated environments and enterprise deployments. We’d especially appreciate feedback from people who have built and/or used browser agents, RPA systems, desktop automation, or agent infrastructure. We’re curious which parts of the API you would want direct control over, where you would prefer higher-level abstractions, and which failure modes have been hardest in your own automation systems. If you've hit weird failure modes automating software like this, we want to hear about them. We'll be here all day answering questions and taking notes!

IN

Intunedhq

Hey HN, we're Faisal and Ahmad from Intuned (https://intunedhq.com). We’re building a platform for building, deploying, and maintaining browser automations. Customers primarily use the Intuned AI agent to automate websites that don't expose APIs. Common use-cases include scraping data, pulling reports, and submitting forms. As the website changes, our agent also helps automatically heal the automation. On Intuned, browser automations are created by an AI agent and run as code. Our infra captures the context of every run, allowing our agent to debug and maintain the underlying code - to keep the automations working over time. This way, we’re able to offer the predictability, speed, and cost of code, without the painful parts of writing and maintaining it. Here’s a demo of building a scraper on Intuned: https://youtu.be/ruZP73bK4FU Here’s a demo of using AI to maintain a project: https://youtu.be/e4R4hLdHBro Backstory: we were accepted into YC for a completely different idea. During the batch, because of Faisal's background at UiPath, several batchmates asked us whether RPA tools could fill API gaps in their products by automating websites without APIs. When it was time to pivot, we went back to those founders to dig deeper. (RPA in this context is referring to using UI automation to do complete non-testing tasks) We discovered that the actual hard problem in browser automation is maintenance. Websites change, selectors break, and failures can be painful to reproduce and fix. So in early 2024, we decided to take a crack at this problem with a handful of customers. It needed a fair number of iterations before we landed on our current code-first approach. How it works: Intuned is infra + agent, deeply integrated. On the infrastructure side, Intuned is a managed runtime for browser automation code. Projects are usually Playwright-based TypeScript or Python. Users can write them directly in our online IDE, or hand the work off to the agent. Either way, once deployed, the platform runs each project in its own isolated machine and handles auth/session reuse, scheduling, batch execution, concurrency, observability, and the other plumbing around running browser code. On the agent side, it took us a few iterations to get to the current approach. Our initial attempts were rigid pipelines: collect requirements, inspect the site, generate code, then try to patch whatever broke. It looked reasonable on paper, but real websites are too messy for fixed paths. Late last year, we were planning to ship that version when stronger models landed and harnesses like Claude Code and Codex showed what a more open-ended coding agent could do. We built a prototype on the Claude Agent SDK, it felt much better than what we had, and we scrapped the release and decided to rebuild the agent. The rebuild came down to three pieces around the SDK: an execution environment for running long agent sessions reliably, a CLI that exposes the platform to the agent so it operates Intuned the way engineers do, and a custom plugin (skills + MCP) built around what we've learned building browser automations. The infra-agent integration is where the product gets more interesting. The runtime doesn't just run the automation; it captures the context needed to debug it when it fails: params, results, traces, logs. That enables features like Fix with AI, where you can open a failed run and have the agent investigate and prepare a fix. The same integration powers a feature called self-healing. For configured projects, the platform detects failures, starts an agent session with the relevant context, and either proposes a fix for review or deploys it automatically. Demo: https://youtu.be/IVHIXw0lYMs We recently also packaged the infra and agent as an API called Web Task API, here is a demo: https://youtu.be/1olRn3l95vw We strongly believe that browser automations can and should be faster, cheaper and more predictable. Check us out at https://app.intuned.io/, we have a free tier with trial credits for your first few automations. Excited to hear your thoughts, questions, and feedback!

IN

Integuru

Hey HN! We’re Alan and Richard from Integuru (YC W24). We generate fast, reliable integrations for platforms lacking official APIs. About 2 years ago, we released the first agent that reverse-engineers network traffic to build integrations (https://github.com/Integuru-AI/Integuru). Since then, we’ve developed a new approach to reverse-engineer platforms’ source code directly. This solution also includes authentication support. Here’s a demo: https://youtu.be/4l2L8fILC2g?si=nbWbDiFrWZIWRPM7. Many AI products need to integrate with web apps, but platforms often lack official APIs. So far, there are two main ways to integrate: browser automation and via network requests. We set out to build the original agent because we ourselves suffered from RPA’s latency, reliability, and throughput issues. The original agent solved many of the prior issues, but it wasn’t perfect either. The original agent did things the obvious way: (1) have a human do the action; (2) the agent observes the network requests and (3) recreates them. That got us far, but it only supported the path the user triggered. In production, we saw all the uncovered cases: different states, missing fields, permission differences, hidden validations, and request changes we could never catch in a single run. So we started building a new solution from the ground up. Our first step was to add agents that trigger many variations of the same action. To protect the platform’s data integrity, we added a gating layer that blocks outbound requests. This lets us observe the exact request structure, branching behavior, and platform logic without accidentally mutating the live system. But this still wasn’t enough. Some logic is hard to surface by execution alone. A lot of the business rules live in the frontend bundle. So we set out to analyze the true “answer sheet” for each platform: the source code. After experimenting, we got this working. We built a source-code analysis layer that deobfuscates and traces the code associated with each action. In practical terms, our system can handle most tricky edge cases without triggering all flows. Together, these two layers result in much better coverage of the production surface area. They support more edge cases, fail less often, and avoid a lot of the brittle one-off fixes that usually come later. Finally, we added auto-healing and API doc generation to improve reliability and the UX. We also offer a 24/7 on-call maintenance team for companies on the production plan. We now spend most of our time supporting vertical AI companies and helping them connect to their customer systems. We offer a free plan for integrating with one platform and charge for additional platforms, accounts, and overage API calls. For instance, we help healthcare AI companies connect to EHRs and payer portals, and logistics companies connect to TMSs and ERPs. Some companies are now running more than 1M monthly requests per platform. Across our production users, API calls complete in ~3 seconds at 99.9%+ success rate on average. We’re also building a library of APIs that users can use out of the box. That said, this version still has limitations we want to iterate on. Although we already tackle some anti-bot mechanisms, the agent still struggles to generate integrations with heavily anti-botted platforms. When the agent fails, our on-call team steps in to improve the agent or build the integration manually if the customer requests it. Also, the UX for generating an integration is still quite manual. Our next step is to build a CLI experience, so people and their agents can create, test, and use integrations in a much more flexible manner. This also prevents humans from having to wait for Integuru to finish its tasks. We want to one day allow developers and agents to integrate with all platforms instantly. Integuru is an ongoing effort. We’re passionate about automating integrations and would love your feedback!