PH热榜 | 2026-06-25

@barath_kanna_bk Love the idea of choosing the right model for the job instead of locking into one from day one. The model comparison feature looks super useful. 🚀

@barath_kanna_bk Many congrats on the launch, Barath. I liked the idea when you presented to me... having one API for 35+ models with predictable pricing will surely help the AI teams. Good luck with the launch! :)

@galdayan Thank you Gal, you captured the problem really well.

Agent workloads are exactly where the forecasting issue becomes painful because a single user action can turn into multiple reasoning steps, tool calls, retries, and model calls behind the scenes.

On the mechanics, today developers explicitly choose the model per request. We believe that control is important, especially for teams that care about quality, latency, and predictable behavior in production.

That said, cost-aware routing is definitely part of the direction we want to move toward. The idea is exactly what you described: give teams an optional layer where they can optimize for cost, latency, or quality depending on the task, while still keeping the final control with the developer.

Our current focus is to make access predictable and reliable first. From there, smarter routing and optimization can become a powerful layer on top.

Out of curiosity, what kind of agentic workflows are you building, and how are you currently managing model selection and spend as they scale?

@harini_mukesh Thanks for the question!!

From our perspective, we believe that trust is earned when users starting using our APIs in production environments from their initial testing clusters.

Reliability, cost predictability and privacy are the foundations of trust. If developers can confidently build, compare models, and scale without worrying about outages, unexpected bills, or their data being used for training, Oxlo.ai becomes infrastructure they can depend on every day.

We are still early, but that is the standard we are building toward.

@lakshya_singh Thank you so much Lakshya.

@nikitaeverywhere Thanks for flagging the calculator, Nikita. Our team will improve its mobile responsiveness and get that fixed soon.

We self-host the models, and our subscription plans include usage ceilings appropriate to each plan. We are not claiming to offer unlimited access for a small fee.

Our approach is to keep margins as lean as possible to make AI model access more affordable and encourage adoption. We aim to remain among the most cost-effective API options while maintaining a sustainable service.

@thamibenjelloun Developers interact with a single OpenAI-compatible API, so the request and response format is normalized across all supported models. That means switching between providers typically only requires changing the model field rather than rewriting application logic.

Of course, each model still has its own strengths, latency, context window, and capabilities, so those differences remain for developers to choose based on their use case.

@artstavenka1 Thanks Art,

Curious what kind of models you're using. Some of our users run multiple claw instances backed by Kimi K2.6.

@yashchoudhary Thanks Yash,

Curious if you're working with any AI models through an API.

@dhanrajchoudhary Thank you Dhanraj, that comparison with BOM optimization is exactly the kind of problem we are trying to solve for AI teams.

On latency, each model has its own performance profile, so we do not promise identical response times across every model. Developers select the model based on the task and their latency, quality, and cost requirements.

Oxlo.ai does not silently switch models within an active request. The API routes the request to the model selected by the developer, while our platform focuses on keeping the serving layer reliable and reducing unnecessary infrastructure overhead.

We also make it easier to compare models and calibrate parameters before deployment, so teams can identify the right balance of quality and speed for each use case.

For real-time interfaces, faster models can be used for interactive flows, while larger reasoning models can be reserved for tasks where response quality matters more than latency.

Really appreciate the thoughtful question and curious what kind of models you're using at Dune.

@mssulthan Thanks Sulthan for the wishes.

Curious what kind of workloads or models you're leveraging at CodeDesign.

@umar_saleem Our model stack is been battle tested for running agents in production. so far our users have been happy about our uptime and latency.

We also offer dedicated GPU deployments with SLAs for enterprise customers, so reliability is ensured.

Curious, what model are you currently using at Todai.

@martin_mo Thank you Martin!

Since you’re running an AI image generator, you probably know this pain very well.

Today, routing is controlled by the developer. Users explicitly choose the model through the API request, so we don’t silently switch models based on cost.

We think quality, latency, and cost all matter differently depending on the workflow, so we want teams to keep that control. Over time, optional routing based on cost, latency, or quality is definitely something we want to explore.

Curious what models you’re using for image generation today?

@fberrez1 Great question.

Today, Oxlo does not automatically route requests or switch models behind the scenes.

Users control model selection directly through the model field in the API request. That means teams decide which model fits each task, whether they are optimizing for cost, latency, context length, tool-calling behavior, or output quality.

Our savings come mainly from optimized infrastructure, and keeping margins lean, not from silently sending requests to cheaper models.

We also avoid hiding model differences. Context windows, tool-calling behavior, and latency vary by model, so developers keep explicit control rather than relying on automatic routing that could break production workflows.

Out of curiosity, what does your model stack look like at Foyer today? Are you using different models for different tasks, or mostly standardizing on one provider?

@matheusdsantosr_dev Thanks for the feedback Matheus.

We will definitely add a request cancellation feature soon in the playground!!

Happy to explore synergies together!!

@pt_tango_ag Hi Przemek,

We have a dedicated section in the Oxlo.ai playground to test, compare and calibrate each model that we have before deploying it in your agent / app. This also helps to evaluate how tokens consumed by different models for the same prompt for very accurate calibration and fine tuning!!

@angelika_dev Good question.

Users control model routing directly through the model field in the API request. We do not automatically switch, update, or route models on their behalf, so teams retain full control over the model they use in production.

@wojtekszkutnik Thanks Wojtek.

Kimi K2.7 is coming up ver soon on Oxlo.ai.

@sidraarifali Yes sidra,

That is absolutely right, earlier when we were building an agentic for ourselves we saw our bills go from $100 / month to around $2000 in a matter of weeks, the problem was not the costs but how quickly they went up insidiously!!

@moon10 Thanks Moon,

Curious if you are currently using any models in production.

@hamza_afzal_butt  Thanks Hamza,

Yes, most of our users feel the same too.

@susiewang Thank you for the thoughtful question.

Today, Oxlo.ai gives teams explicit control over model selection. Developers choose the model that best fits each task, whether they are optimizing for quality, latency, reasoning capability, or a specific use case.

Our main focus is to provide a unified and reliable way to access and compare models through one API, while keeping costs predictable through fixed subscriptions. We also let teams compare outputs and adjust model parameters so they can evaluate the right balance of performance and response quality before deploying.

Over time, we see optional intelligent routing as a natural next layer, where teams could set preferences around cost, latency, or quality. But we believe developers should retain control over those decisions, especially in production workflows.

@etiennegarcia Thanks Etienne,

That was a great catch, we will fix that typo soon!!

@etiennegarcia Fixed already!!

@chilarai Thanks for the comment, Chilarai!

We offer two subscription plans for different stages of builders: one includes up to 1k calls / day, and the other includes up to 5k calls / day. These plans are designed for developers, solo builders, and early-stage teams.

For customers who need higher limits, we offer custom fixed price plans based on their historical usage. We commit to a fixed monthly price that is at least 15% lower than their current AI spend, with a usage ceiling of up to 1.5× their committed usage.

This gives teams room to grow while keeping their AI infrastructure costs predictable.

@vikramp7470 Thanks for the comment Vikram.

We have a soft limit which sends warnings and upgrade prompts in advance in case the request limits are reached so users can promptly upgrade their plans to stay up always.

@creativewjordyn Thank you so much Jordyn!

Yes, the dashboard gives you a real-time breakdown of your usage across models, including requests, tokens, and estimated value consumed. Since you’re on a fixed subscription, it’s less about tracking what you’ll be billed and more about understanding where your usage is going and how different models are being utilized.

That visibility also helps teams compare models and optimize their workloads over time without worrying that experimenting with a different model will suddenly increase their bill.

@sameerkatel Access 35+ frontier AI models through one API and one monthly subscription, so you can focus on building instead of managing infrastructure.

@lana_wang Thank you for trying it out and for the honest feedback!

There is a small overhead from our gateway, but we’ve worked hard to keep it minimal. We’ll continue optimizing the serving stack as we scale.

On privacy, that’s one of our core priorities. We never train on customer data, and we’re continuing to strengthen the platform with more privacy and enterprise-focused capabilities over time.

Really appreciate you taking the time to test Oxlo.ai, and we’d love to hear any other feedback as you continue using it.

@arjayyy Switching is very easy since all providers use the Open AI API format, Users can switch by just changing a couple of API fields and it takes under 5 minutes.

Cost savings are also instant as you pay for a full month upfront.

@kiran_kadekoppa Thank you Kiran!

Today, we primarily rely on the safeguards and moderation capabilities provided by the underlying models. Our focus has been on providing a reliable, API layer with predictable pricing.

That said, as we onboard more enterprise customers, additional governance features such as centralized policies, usage controls, and organization-level guardrails are definitely on our roadmap.

@sabber_ahamed We don't route user prompts, users decide which model they want to use for every prompt.

Savings come from self hosting and efficient management of resources and of course keeping our margins very thin to acquire customers :)

@wendyba Congrats on the launch. :)

BrowserAct seems like a practical way to help agents navigate the messy web flows. What kind of browser task has been the hardest to automate so far?

@wendyba Great launch. Quick question: When BrowserAct hands off to a human during a stuck flow, what does that experience look like for the person assisting? Specifically, how does the human see the current browser state and what steps are required to resume?

@galdayan Good question. I don’t see this as a choice between neat output and separate session isolation—we actually need both, and they all tie back to the core idea behind BrowserAct: keeping workflows running reliably on live real sites.

Clean output stops the agent from drowning in messy raw DOM data so it can make better decisions. Session isolation is critical if you’re running multiple parallel tasks, staying logged into different accounts, or handling account-specific work. Things like cookie popups, active login status, captchas, blocked pages, manual confirmations, or short human intervention breaks all feed into one single goal: let the agent keep progressing and wrap up tasks fully.

This is where we think BrowserAct stands out. Instead of the agent dying quietly or having to restart the whole process every time something goes wrong, we built it to hold onto your active browser workflow no matter the interruptions.

A quick contrast to similar tools: Unlike Browserbase, we aren’t just building basic browser backend infrastructure. And versus Browser Use, our focus isn’t solely on simpler browser control. We built BrowserAct as a browser layer purpose-built for AI agents. It bundles isolated sessions, streamlined readable page data, automatic verification handling, and human takeover functionality—all tailored for those messy, unpredictable real-world automation flows.

@abod_rehman Great question. It’s not really a single confidence threshold.

The agent reads the live browser state and follows an escalation path. For normal UI changes, it can wait, re-check the page, and adjust the next action. If it detects a common verification challenge, BrowserAct can try automated handling with commands like `solve-captcha`.

But when the step clearly requires human identity or judgment, such as login, 2FA, OAuth, a security check, a QR scan, or manual confirmation, the agent should stop retrying and hand off through headed mode or `remote-assist`.

If the workflow needs a person, BrowserAct keeps the same browser session alive so the human can clear the step and the agent can continue from there.

@varunvivek  Thanks so much, that means a lot. We designed BrowserAct for agents first, with things like anti-detection, better headless mode, remote assist, browser modes, and strong concurrency/isolation. The goal is to make browser tasks keep moving even when the web gets in the way.Would love to hear how it works on your proposal workflows once you test it.

@malithmcrdev Yes, a bit different. Tabstack feels more like a managed API for clean structured output, while BrowserAct is more like a browser layer for agents to actually interact with real sites. We focus more on using real Chrome sessions, handling logins/CAPTCHAs, and letting agents keep going when websites get messy.

@rahulbhavsar With BrowserAct, the agent can inspect the current browser state, take an action, wait for the page to stabilize, and then re-read the latest state before moving to the next step. That helps with dynamic UI changes, layout shifts, and brittle page flows.

For sensitive or uncertain steps, BrowserAct uses confirmation gates and human handoff instead of letting the agent guess. If the workflow reaches login, verification, 2FA, manual approval, or any step that needs a person, `remote-assist` lets a human take over and then allows the agent to resume from the same browser session.

@itsluo Yep, this was our main pain point to tackle.

It’s easy to automate basic clicks in a perfect environment, but actual browser work gets interrupted all the time: logged-in states popping up, verification windows, blocked pages, parts you have to judge manually.

BrowserAct’s built to preserve your ongoing workflow. The agent can pause, recover, or let a human take over without wiping your session and starting over again.

@yagnaveena Browserbase + Playwright give you a remote browser; they don't give you the layer that keeps agents reliable when sites change. Specifically:

• LLM-in-the-loop recovery when selectors break or DOM shifts mid-flow

• Skills — open-source, versioned, composable task definitions (so you're not locked in)

• Structured per-step verification (screenshot + DOM diff events) for debuggable agent runs

• Managed anti-bot, session persistence, captcha, proxies — one layer instead of five

• Native MCP, so any agent gets browser hands without glue code

You can build all of this — most teams we meet spend 6–12 months doing exactly that before deciding the leverage isn't there. If browser automation is your product, build it. If it's a means to an end, we'll give you that time back.

@artstavenka1 

In BrowserAct’s stealth browser, the browser environment can be aligned with the configured IP region, including things like language and timezone. If IP stability is the concern, using a static IP gives the browser a much more stable environment.

For a persistent/fixed browser setup, if a session is already open and you want changes like IP or region settings to take effect, you need to close the active sessions first. In private mode, a new session can pick up the new environment.

So I’d say BrowserAct helps keep the browser session and environment stable. The safer pattern is one stable browser identity per region.

Does that match your understanding of the issue? If I’m missing something, please correct me.

@avery_thompson2 Thank you!

The first big challenge was anti-bot challenges and interactive verification. Real sites don’t just need clicks, they bring CAPTCHA, login checks, 2FA, blocked pages, and changing UI.

So we built the escalation path early: real Chrome sessions, stealth mode, `solve-captcha` for supported challenge flows, and `remote-assist` when human help is needed.

@boyuan_deng1 
That’s a great question. We can’t offer a fixed universal success rate, as performance hinges on the target site, account history, traffic patterns, proxy quality, login state and task type.

Our solution is built around three functional layers. The first is our foundational browser environment, with native Chrome sessions, stealth configurations, session persistence and streamlined data extraction.

Second comes automated verification handling. When sites trigger anti-bot measures, BrowserAct detects blocked pages and runs tools like the solve-captcha command to resolve standard CAPTCHA and verification prompts where feasible.

Third is human handoff. If automation can’t clear a barrier, team members can intervene, and the agent resumes work within the original session afterward.

We don’t position BrowserAct as a tool to circumvent all site restrictions. Our core priority is uninterrupted task delivery, with zero loss of existing session progress.

@divvsaxena  Thanks for your interest! We actually do have demo videos available — And if you'd like a more in-depth walkthrough, we'd be happy to schedule a video call demo at your convenience.

@monir_ Thank you! Really appreciate it. Would love to hear how it works for you

@thamibenjelloun Yes. BrowserAct supports both paths.

If a verification flow is supported, the agent can use `solve-captcha` to handle it automatically. For flows that need human identity or judgment, the agent can use `remote-assist` with an objective, so a person can step into the active browser session, complete the check, and let the agent continue from the same state.

@sameerkatel Great question. If I had to pick one practical difference, it would be identity isolation.

BrowserAct is not just about clicking pages. It gives agents a browser identity layer: stealth browser mode, privacy mode with fresh fingerprints, fixed-identity mode with stable IP and session state, proxy options, and isolated cookies/profiles across browsers.

The goal is to reduce unwanted correlation between runs or accounts, and keep the browser environment consistent enough for real workflows. When verification still appears, BrowserAct can use `solve-captcha` for supported challenges or `remote-assist` when a human needs to step in.

So the biggest difference is not only automation, but helping agents operate with controlled browser identity, session isolation, and recovery when websites push back.

@sameerkatel Great question! The biggest practical difference is reliability of the result, not just the action. Most browser automation tools fire off the steps and report "success" the moment the script finishes — even if the page didn't actually load, the data came back empty, or a popup silently blocked the click. BrowserAct verifies each step actually produced the intended outcome before moving on, so your agent doesn't quietly hand you broken data. Once you run a few real workflows you'll feel the difference. Would love to hear what you build with it!

@arthur_winston3 Thank you! Really appreciate it. Would love to hear how it works for your workflows after you try it.

@hanzhizhang0405 Thank you for the support! We’d love to hear your feedback after you try BrowserAct in your own workflows.

@peng_wood Thank you! Really appreciate it. Would love to hear how it works for your Agent after you try it.

@noice30sugar Thanks! This is one of the core design points in BrowserAct.

BrowserAct separates browser identity from session workspace. If agents need isolation, each agent can run against its own browser identity with separate cookies, fingerprint, proxy, and login state.

If they intentionally need to work under the same account or browser context, they can open multiple sessions on the same browser. Those sessions share login state, but each has its own navigation and task flow, so parallel work does not block the others.

So the model is flexible: separate browsers for isolated agents, multiple sessions on one browser for shared-account workflows, and privacy mode when you want zero residue.

@sabber_ahamed Great question. BrowserAct does not lean on stale selectors or fixed coordinates as the source of truth.

The core model is live, indexed browser state. The agent calls `state` to get the current interactive elements, acts on the current index, waits for the page to stabilize, and then re-reads state when the page changes.

So when the DOM shifts, the pattern is not “reuse the old selector and hope.” It is “refresh the current page state, get fresh action targets, then act.”

Visual inspection can help in some cases, but the main reliability path is compact state + indexed actions, designed for agents rather than hand-written selectors.

@tkeith Great question. To set expectations clearly: BrowserAct does not claim to fully auto-solve every complex CAPTCHA, especially on datacenter IPs, which often trigger stricter anti-bot checks.

We handle verification challenges in three layers.

First is the environment layer: stealth browser profiles, persistent sessions, proxy controls, and static proxy support. This helps keep the browser fingerprint, IP region, language, timezone, and session context consistent across runs.

Second is automated verification handling. If a supported CAPTCHA or verification challenge appears during the task, BrowserAct can use `solve-captcha` to handle it where possible.

Third is human handoff. For tougher challenges that require a real person, `remote-assist` lets a human step into the active browser session, clear the verification, and then the agent resumes from the same state.

The goal is to keep legitimate agent workflows moving through real-world verification friction without losing progress or breaking the session.

@riley_shu Thanks！BrowserAct is focused specifically on browser workflows for agents: real Chrome sessions, indexed page state, session isolation, stealth mode, proxy options, verification handling, confirmation gates, and `remote-assist` when a human needs to step in.

So the way we think about it is: Codex or another agent can do the reasoning and task planning, while BrowserAct gives it a stronger browser execution layer for real websites.

@yannikga Good question. Yes, re-reading live browser state adds a bit of latency, but in most real workflows it is much cheaper than acting on stale state and breaking the task.

BrowserAct can re-read the latest browser state before important actions, especially after navigation, layout shifts, form submissions, or human handoff. That helps the agent avoid stale element positions on dynamic pages.

So the tradeoff is intentional: a small amount of latency for much better reliability.

@ilko_kacharov Exactly. That is very close to how we think about it.

For many real workflows, the web is not just an endpoint to call. It is a stateful environment with login state, sessions, dynamic UI, verification, and interruptions.

BrowserAct is built to give agents a browser layer they can operate in: isolated sessions, real browser state, clean data, verification handling, and human handoff when needed.

@christian_knaut 100% — this is the make-or-break for any agent doing more than one step. Short answer: sessions persist, auth state is reused across tasks. Happy to walk through how it works for your specific workflow if you want — DM me and I'll show you a multi-step example end to end.

@krekeltronics This is exactly the framing we keep coming back to. A demo that completes the happy path isn't useful — an agent you can hand off to and resume from is. We're building toward three things specifically: a session state snapshot the user can actually read (not just a log), an explicit diff between agent actions and human edits, and resume from a named checkpoint rather than 'start over.' Still rough in places, but you've put your finger on the work that matters most. Curious what you've seen work elsewhere.

@himani_sah1 Thank you! Really appreciate the support.

@moon10 Thank you! Really appreciate the support.

@wilder_dev Thank you!

This is exactly the pain point we set out to address. Real-world website workflows inevitably hit steps that require human intervention.With BrowserAct, the automation can pause, pass the intact live session to a user, and resume right where it stopped—without discarding any existing progress.

@johnsy 
Thanks for your thoughtful question!
BrowserAct handles verifications through a tiered workflow.
It runs commands like solve-captcha to resolve standard verification challenges automatically.
For steps that demand real human identity or manual input—including logins, 2FA/MFA, OAuth, QR sign-ins, SMS/phone checks, security keys, biometric confirmation, drag CAPTCHAs and manual approvals—BrowserAct triggers human handoff via the remote-assist feature.

Yannis here, also on the team.

Adding a bit to what Michael said. The thing that got me excited about Zaro wasn't any single feature, it was watching what happened after teams started using it for a couple of weeks. The work it takes over isn't the flashy stuff, it's the quiet drag that nobody puts on a roadmap but everybody feels. The follow-up that slips, the report that takes an afternoon to pull together, the handoff between two tools that someone has to babysit.

We spent a lot of time making sure it actually fits how people already work rather than asking them to change everything. That sounds obvious but it's the part most tools get wrong.

If you're trying it today, the best thing you can do is point it at the most annoying recurring task on your plate and see what it does with it. That's where it clicks.

Happy to answer anything about how it works under the hood, the context infrastructure side, or where we're taking it next. I'll be in the comments all day alongside Michael.

@zaro_ai congrats on the launch! Quick question from someone juggling too many tools: what’s the simplest, highest-impact Zaro automation you’d recommend a solo founder or 2‑person team set up in the first hour to feel immediate relief?

@zaro_ai The one-prompt app building with no glue code is what'll make this click for ops teams immediately. Congrats on the launch Michael!

@galdayan You've nailed exactly the bet we're making, so thank you for that framing.

On the messy and contradictory part, this is honestly one of the hardest and most interesting problems we work on. The short version: Zaro doesn't silently pick a winner and bury the conflict, because that's where automation quietly does the wrong thing with full confidence.

When sources disagree, the goal is to surface the conflict rather than inherit it. A Slack thread saying one thing and a research doc saying another should show up as exactly that, a flagged disagreement with both sources visible, not a single answer that hides which one it trusted. Recency, source, and who said it all factor into how it weighs things, but the principle is that ambiguity should be made visible, not flattened.

I'll be straight that this is an area we're actively improving rather than calling solved. Conflict detection is easier on factual data than on softer "what did we decide" judgment calls, and that second category is where we're putting a lot of the work right now.

Would genuinely love to hear how you'd want it surfaced, since you clearly live this problem.

@syed_shayanur_rahman 

Great question, and a useful nudge. The honest answer is that a polished role-by-role library is something we're building out rather than something fully fleshed out today. The patterns you mention, recruiting ops, founder workflows, support reporting, are exactly the kinds of use cases we want front and center, because most people find it easier to start from an example than a blank page.

In the meantime, the best way to find what fits your role is to point Zaro at the most repetitive task on your plate and describe what you want, it's pretty good at taking it from there. And if you tell me what you'd build for, I'm happy to point you in the right direction right now.

Genuinely helpful to hear there's appetite for this, it pushes it up our list.

@yagnaveena The short version: vector stores and traditional databases were built to answer queries, not to do work.

A vector store is great at "find me the chunks that look similar to this," and a database is great at "return the rows that match this." Both assume something outside the system already knows what it's looking for and how the pieces relate. For an agent doing real operational work, that assumption breaks.

The gaps that hurt most:

Retrieval isn't understanding. Pulling the top-k similar chunks gets you text that's nearby in embedding space, not the actual context of a decision, who said what, when, in response to what, and what superseded it. Agents kept getting plausible-looking but contextually wrong material.

No notion of state or change over time. Operational reality moves. A decision made in a Slack thread last week overrides the doc from last month. Flat vector stores treat both as equally true and have no native sense of recency, supersession, or "this is the current state of things."

Relationships get flattened. The connection between an email, the task it created, and the person who owns it is exactly the context that matters, and chunk-and-embed throws most of it away.

So it wasn't that those tools are bad, they're great at what they were designed for. They just weren't designed to be the working memory of an agent that has to act, not just retrieve.

That's the layer we rebuilt.

@iamanantgupta 

By default, Zaro pulls the context that's relevant to what you're asking for. When you describe what you want to build, it looks across your connected sources and pulls in what relates to that task rather than dumping everything in. Relevance, recency, and source all factor into what it reaches for.

On manual control, yes, that layer matters a lot to us. The goal is never a black box where you just hope it grabbed the right things. You can see what context it's drawing on and steer it, point it at specific sources, scope it to what you want included, and exclude what you don't. Automatic by default, but with you in the driver's seat when you want to be.

@suryansh_tiwari2 Thanks so much!

Honestly, existing automation tools were where we started, and they're great until you hit the wall. They're built for fixed if-this-then-that workflows. The moment something needs judgment, context, or a step that wasn't mapped out in advance, they break or hand it back to a human.

What we kept running into was that real operational work isn't a clean flowchart. It needs to understand context, adapt, and actually carry a task end to end. That's a different foundation, not a smarter trigger on top of the old model. So we rebuilt the context infrastructure underneath rather than bolting agents onto tools that were never designed for them.

Short version: automation tools connect steps, Zaro understands the work. That gap is the whole reason we built it.

Happy to go deeper on any of this if you're curious.

@suryansh_tiwari2 Hey thanks Suryansh!

We determined through working on agents for a while that calling data for existing databases were inefficient and inaccurate. We had to rebuild a database (context layer) to make it really easy for agents to work with. It allows us to do very interesting things such as build end to end apps and tie multiple agents into the application you've just created.

You'll notice that accuracy is substantially higher on the platform compared to others. Let us know what you end up building!

@kate_ramakaieva Zaro starts from a different place.

Instead of you mapping every branch, it works from the actual context and figures out the path, so complexity is something it absorbs rather than something you hand-configure. Less "build the flowchart," more "describe the outcome."

Those connector tools are great for deterministic plumbing, we're aiming at the messier work that doesn't fit a clean diagram.

Happy to go deeper on a specific workflow if you've got one in mind.

Thank you, that means a lot, and you've put your finger on exactly the thing we bet the whole product on.

The builders you're thinking of are genuinely great at turning a description into an app. The gap is that they start from a blank slate, you bring the context to them. Our bet was the opposite: the context already exists, scattered across the tools you live in, so the real unlock is building on top of that rather than asking people to recreate it.

Whether others move in this direction over time, who knows, but it's a different starting assumption, not just a different feature.

Appreciate you getting what we're going for. 🙌

@conduit_design A few that stuck with me:

Someone built a tool that watches their inbox and Slack for anything that looks like a commitment they made ("I'll send that by Friday") and quietly keeps a running list so nothing slips. Simple idea, weirdly life-changing.

Another person wired up a recruiting ops flow that pulls candidate context scattered across threads and docs into one clean view before every interview, so they walk in actually prepared instead of skimming five tabs.

And on the lighter end, the office birthday cake thing is real, someone genuinely built a workflow that automatically orders cakes at the office when's somebody's birthday

@nuseir_yassin1 yes that's available on our platform :)

@krutiparekh16 Zaro is designed for non technical user , you build/edit/update agent/workflow/app all in natural language !

@nikitaeverywhere 

Claude Cowork is an agent that sits on your desktop and executes tasks for you, point it at your files and apps, describe an outcome, and it does the work end to end. It's brilliant at that. The unit is the task: you ask, it runs, you get a deliverable.

Zaro is aiming at a slightly different layer. We're less about running a task on request and more about the persistent context infrastructure underneath, so the things you build (apps and agents) stand on a shared, living understanding of how your team operates rather than re-deriving context every run. The output isn't just a completed task, it's a durable app or agent your team relies on over time, with the maintenance and stability that requires.

So it's less either/or than it sounds. One is an agent that does the work; we're building the context foundation that persistent apps and agents run on. Honestly a lot of respect for what they've shipped, the whole category moving toward agents doing real work is good for everyone.

@manikandanux The work Zaro does isn't tied to individual seats, it spans your whole team. The context it runs on lives across the organisation, the apps and agents you build get used by everyone, and the busywork it removes isn't one person's problem, it's the team's. Charging per seat would mean penalising you for adding the very people who benefit, which pushes teams to limit access to save money. That's backwards. We'd rather the whole org use it freely and pay for the value created, not the number of logins.

It also pairs with the credit model: you pay for what Zaro actually does, not for capacity sitting idle. Per-organisation plus credits means the price tracks usage and outcomes rather than headcount.

@priyankamandal Fair to want the mechanism behind that line rather than just the promise, those claims are easy to make and harder to back.

The honest framing: "gets sharper" comes from the context layer accumulating, not from anything mystical. As you work, Zaro builds up a richer picture of how your team actually operates, what your terms mean, who owns what, how decisions tend to get made, which patterns repeat. So the next thing you build starts from that shared understanding instead of a blank slate. The improvement is mostly context compounding rather than the model itself retraining on you.

Feedback in the more direct sense, you correcting or steering outputs, feeds the same loop: corrections become part of the context it draws on next time, so it stops making the same wrong assumption.

@hamza_afzal_butt Love this, and it's very much the direction we're pulling toward. The agent does the work, the dashboard shows you what it's doing and where things stand, two halves of the same thing rather than two separate builds. Taking a messy recurring process and getting both out of one description is a great way to put it.

@olivia_bennett7 This is a great one, and it's high on our wishlist too.

The logic writes itself: if Zaro can already see the work happening across your connected tools, it's in the perfect position to notice "you do this same thing every Monday" and offer to take it off your hands before you even ask.

Proactive instead of waiting for you to describe it.

It's not something we're calling done today, but it's exactly the kind of direction the context layer makes possible, and hearing people actually want it pushes it up the list. Appreciate you flagging it.

@angelika_dev 

This is a sharp concern and you're right to raise it. Self-updating is powerful but for operational work that people depend on, unpredictable change is a liability, not a feature. Nobody wants the thing that ran payroll yesterday quietly behaving differently today.

The way we think about it: adaptation should be something you opt into, not something that happens to you. For anything people rely on, you'd want to lock or version an app once it works, so it stays stable and only changes when you decide to update it, with the option to see what changed and roll back if you don't like it. Think of it like pinning a version rather than always running latest.

So the short answer to your question is yes, that control is exactly the direction, stability by default for the workflows that matter, adaptation where you want it.

@istiakahmad Thank you, appreciate that.

You've picked out the part that matters most to us. Any one of those three on its own is something other tools do. The combination is the bet: context to build on, generation to make it fast, and maintenance so the thing is still working next quarter instead of rotting the moment reality shifts. That last piece is the least flashy and the one we think actually decides whether something sticks.

Thanks for getting what we're going for.

@sabber_ahamed You're pointing right at the hard part. Generation is the part everyone sees, retrieval quality is the part that decides whether the thing is actually trustworthy, and stale context is the quiet killer because the agent has no idea it's wrong. It acts with full confidence on a decision that got reversed last week.

The principle we build toward is that context can't be a flat pile of text where everything is equally true forever. Recency and supersession have to be first-class, a decision made in last week's Slack thread should outrank the doc from three months ago that it overruled, and the system needs a notion of "this is the current state" rather than "here's everything that's ever been said." That's a big part of why we argue the old vector-store model falls short: top-k similarity has no sense of what's still true, only what's textually similar.

I'll be honest that this is exactly the area where the work is never finished. Detecting that context is stale, especially for soft judgment calls rather than hard facts, is an ongoing problem, and we treat surfacing uncertainty (flagging "this may have changed") as part of the answer rather than pretending we always get it right.

@Brain  @djcurfew @thisiskp_ Good hunt and very interesting launch! :)

I am impressed by how ClickUp is pushing productivity into a full AI workspace. What’s the biggest workflow improvement you’ve seen so far?

@Brain  @djcurfew Well done, Zeb and crew. "Context Collapse" might be the clearest idea I’ve seen on Product Hunt lately. Teams keep bouncing prompts across ChatGPT, Claude, and Gemini, stuck in a cycle they never asked for. Few even question it anymore; it just comes with running AI tools today.

Imagine building something that grows stronger every time it's used. When a group relies entirely on one AI system, leaving feels nearly impossible. The deeper they go, the harder it gets to walk away. Strength hides in that grip.

Here’s something odd - Brain² treats mismatched inputs not by picking sides but through layered interpretation, letting each team keep its version while mapping overlaps behind the scenes. When sales claims X yet product insists on Y, it doesn’t force harmony; instead, it surfaces both truths side by side with traceable sources. Now imagine regions where laws forbid data movement beyond borders - tricky, right? Well, suppose you’re handling EU health records or APAC finance logs; storage paths split accordingly. Instead of centralizing everything, processing happens locally when needed, so compliance isn’t an afterthought. These aren’t edge cases - they form the core tension in any enterprise-scale knowledge setup. One moment you're aligning narratives, next you're dodging legal traps baked into infrastructure choices.

Curious how things will unfold from here.

@Brain  @djcurfew Giving the AI visibility into an entire company's workflows is bold. Did you find that users wanted more control over what context the agent actually uses, or did they embrace the full visibility?

Totally hear you,@jennifer_lyu ! Brain² confirms before acting, so you see what it plans to do and can approve, edit or reject before anything it lands. For accuracy, it reads from your live Workspace (not a frozen copy), so it stays current as things shift.

@thisiskp_ Hey, KP! Thanks for hunting us and for the awesome intro 🙌 Love how you broke down the "why now" for Brain². Huge props, and thanks for the love! 💜

Hey, @marie_saxon ! Brain² reads from your live workspace, so it's always working with the latest version of your docs, tasks, and conversations. If something conflicts, it links back to its sources for you to trace back. Brain² also has memory. It remembers your preferences, past decisions, and project context across conversations so if a Doc or project has pivoted, it'll adapt!

@iamanantgupta Hey, Anant! Brain² doesn't just pick one source. When it pulls info from your Workspace, it shows you where it came from, so if there's conflicting stuff across Docs, Chats, or tasks, you'll see the sources and can judge which one's actually current.

@david_vilalta Great question, David! The study was designed around real work tasks that required company context, things like pulling from actual projects, Docs, and decisions.

The whole point of the comparison was to test how these tools perform in the environment teams actually operate in, not on generic prompts where no one has a built-in advantage.

So yes, the results reflect what happens when AI has access to your Workspace context vs. when it doesn't!

Great question, @maylee_zhang ! Brain² pulls from your live Workspace (tasks, Docs, Chats), the context stays as current as your team keeps it. It also cites its sources so you can always trace back where an answer came from and decide if it still holds up.

@enrique_chavez4 Love hearing that, Enrique! 🙌 Glad Brain² is saving you real time!

@galdayan Appreciate the question, Gal! When Brain² doesn't have enough info in your Workspace to give a confident answer, it'll tell you straight up. It shows you what it found and where it pulled from.

Brain² reads directly from the system of record because your work already lives in ClickUp. 🙌

@syed_shayanur_rahman Absolutely! Happy to share live examples. We're posting them on our socials this week. We also have live interviews in the streets where we compare against every frontier model.

@syed_shayanur_rahman you can also check out some examples of Brain² in action here: clickup.com/brain

Brain² is the only AI that lives where your work already happens, so it has full context across your tasks, docs, and conversations without you having to brief it. That context is what sets Brain² apart. 🔥

@nuseir_yassin1 Yes, absolutely! Brain² respects the permissions you've already set up, so if something lives in a private Space or a restricted Doc, it won't surface that to people who don't have access. Your team stays in control of what's shared!

@jordangray No need to wait, Jordan! 😉 Brain² is already shipping with model flexibility, MCP integrations, and company-wide memory that compounds over time, so it just keeps getting smarter the more your team uses it.

@sabber_ahamed You nailed it, Sabber! Brain² respects the same permission rules already built into your Workspace.

If a user doesn't have access to a Doc, task, or conversation, Brain² won't surface it to them. The context stays rich without ever crossing access boundaries. 🙌

@harini_mukesh Oh this is a fun one, Harini! I'd say it's gotta be how creative people get with the Hierarchy and Custom Fields. 🔥

We've seen folks build full-on CRMs, content calendars, hiring pipelines… all from the same core building blocks. The platform bends to how you think, and the workflows people come up with still catch us off guard in the best way!

@roopreddy Great question! Brain² gets stronger the more context it has, and you can definitely use it without everything directly in ClickUp!

MCP integrations let it connect to tools you're already using outside ClickUp (GitHub, Google Drive, Slack, etc.), so it can pull context from wherever your work lives.

And as your team uses it more, company-wide memory fills in the gaps. So it's definitely still useful with partial context, and it compounds over time! 🙌

@zerotox we want to make it as quick and easy as possible for you to work with Brain²! And great question! It's pronounced, "Brain Two"!

@angelika_dev Great question, Angelika! Brain² follows the same permission rules already set up in your Workspace. So if someone doesn't have access to a specific Doc, task, or conversation, Brain² won't show it to them.

@krutiparekh16 we couldn't do it without community members like you! Appreciate the support and can't wait to hear what you think about Brain²!

@divya_kothari1  It's really all three working together! Retrieval pulls in the right context when you need it, memory picks up on your team's patterns over time, and orchestration is what lets it actually take action across your workflow instead of just giving you answers.

@ankur_jeswani Thanks Kruti! That's exactly the vision: AI woven into how your whole team works. Glad it resonates! 🙌 Hope you'll give Brain² a try!

@Cluely  @aj_123 huge congrats on the launch, so glad you explicitly stated the goal isn't to replace the human closer. sales tools that try to fully automate the entire pipeline always feel incredibly robotic, but using ai as a live coach during the call is the sweet spot.🙌

@Cluely  @aj_123 

The coaching and roleplay side is a clear win. The AI-initiates-calls-to-real-prospects side is where I'd want to understand the trust dynamic better.

One question I keep coming back to though: for the live AI caller feature specifically, how does it handle the moment a prospect realises they're talking to an AI? Increasingly people can tell, and that realisation mid-call can damage the brand relationship more than a missed call would.

Curious whether you've measured pickup and engagement rates for AI-initiated calls vs human ones — and whether there's a transparency setting where the AI identifies itself upfront.

@chrismessina Chris. This means a lot, especially because you’ve seen the product and the story evolve up close.

Your insights have helped us how we talk about the product and showcase to world (including our landing page).

Really grateful for your help in this whole launch process. And yes, we’ll try to make every agentic tongue lashing useful, not traumatic 😄

@dsculptor Congratulations on the launch! Sales feels like one of the hardest things to do. Excited to try out that feature

@shantanusewu Yes, but we think about “improvement” at 3 levels:

1. Business outcomes: response time, connect rate, qualified leads, demos completed, meetings booked, follow-up completion, and where available, downstream conversion. That's what most our customers care about post pilot.

2. Conversation quality: did the agent ask the right discovery questions, handle objections correctly, follow pricing/qualification rules, know when to escalate, and keep the buyer moving to a clear next step.

3. Learning loop: every call can flag missing knowledge, weak objection handling, confusing product docs, or new buyer patterns. The agent proposes updates, but the human approves what actually becomes part of the playbook.

Hope this helps!

@harini_mukesh I really like how you framed this. The human part is exactly why we started with tough conversations before narrowing into sales.

The most common practice areas right now are discovery calls, pricing pushback, objection handling, demo interruptions, qualification, and follow-ups. Outside sales, people also use it for interviews, feedback conversations, negotiation, and customer support scenarios.

For sales teams, the most interesting pattern is that practice does not stay separate from the real workflow: the same playbook can help the agent call leads, support the rep live, and audit what happened afterward.

Happy to connect offline too if you want to compare notes on the kinds of conversations you’re thinking about.

@cecilia_zeng13 Definitely, an outreach, at least the first level, is the kind of thing that you might want to automate and focus your time in the later cycle of the pipeline. Our phone calling feature can be a good here here!

@yannikga yes, agreeableness is one of the core things we are fighting against.

• Out of the box, we add a clear resistance prompt so the buyer/interviewer does not accept weak answers just because the user sounds confident. It is asked to hold its ground based on the persona, objection, goal, and evaluation rubric.

• We also let users edit and extend that resistance prompt, so you can make the scenario harder to convince over time. If you want a buyer who keeps pushing on ROI, pricing, urgency, authority, or competitor comparisons, you can keep increasing that difficulty.

So yes, the goal is productive pressure: tough enough to expose weak spots, but still realistic enough that it feels like a conversation you might actually face. Would love to connect offline if you want to try a hard scenario and poke at it.

@vgatmaxim thanks so much!

@jared_saloisgreat question.

Most teams do start with onboarding because the value is very clear there.

• What surprised me, though, is that onboarding is almost constant in many sales orgs because of churn and team movement. And even for experienced reps, the ground keeps shifting: new products, new objections, new pricing, new coupons/offers, new competitor narratives, etc.
  

• In very mature sales teams with a stable playbook, the value is less obvious and honestly more challenging. There it becomes more like reinforcement: a way to keep people sharp and make sure everyone is up to date, almost like clearing a recurring exam on the current playbook.

So yes, experienced reps may not “need” it in the same way newer reps do, but I think there’s still something useful there. It’s an area I’m paying close attention to and still learning about.

Would love to exchange notes and connect offline if you’re open to it.

@rahulbhavsar this is exactly the area where I’ve spent the most time researching. Almost every GTM enablement team I spoke with brought up the same risk: if the assistant is always “looking at the call,” it can easily become distracting

• What I found interesting is that only a small set of reps, maybe 20%, feel confident enough to not want any help in the room. Most reps still miss things: pricing nuance, positioning, competitor context, a sharper discovery question, or the right next step. So the design challenge becomes: how do you support them without flooding them?

• Our current POV is that the agent needs to be highly controllable. For example, if a pricing question comes up, it should surface 3 crisp bullets and nothing else. You can create your own agent with strict constraints, connect it to CRM or knowledge sources through MCP/custom functions, and decide exactly when it should surface something.

So I fully agree with your point. The two pieces we’re focusing on are user control and rich context, so the assistant is useful because it knows the situation, not because it is randomly generating prompts.

Would love to hear more of your thoughts on this. If you’re open to it, happy to connect offline: https://cal.com/ajitesh/30min

@marie_saxon you put this beautifully.

I think the autonomy line should be set by the business and by the risk of the conversation.

• For repetitive frontline work like reminders, qualification, basic demos, follow-ups, and booking next steps, an AI agent can act directly if the rules are clear. Most users we interact with find this part less rewarding and boring.

• For high-trust moments, complex objections, pricing judgment, or sensitive buyer context, the better role is coaching/support: bring the right context to the human, suggest what to ask, and help capture what happened.

Would be happy to discuss this offline too. I think this boundary is one of the most important design questions in AI sales.

@pradyumna6great question. For Truely, speed is basically the product. If the context arrives after the moment has passed, it is not useful.

The way we think about it is: prepare as much context as possible before the call, retrieve only the most relevant pieces during the call, and surface short, glanceable help instead of long AI responses. The goal is not to make the rep pause and read a paragraph, but to give them the right fact, objection answer, customer context, or next-step suggestion while they stay in flow.

Latency can vary based on the data source and setup, but we’re designing around live conversation constraints. Happy to connect offline if you want to dig into the architecture or a specific CRM/docs workflow.

@parekh_tanmay Thanks so much Tanmay! We should connect some time to explore we can collaborate and work some project :)

@ruvik_milkis Thanks so much Ruvik! If you have a specific sales flow, demo, or lead follow-up workflow in mind, send it over and I’d be happy to help you set up the first agent.

@aman_garg8 Thank you so much for showing early faith in the product. Discovery is one of the places where voice agents can create very direct business impact, especially when speed-to-lead and qualification quality matter.

@sahilio Congrats on the launch Sahil and team. Been following since what seems like day 1 (maybe day 0!), and so needed within orgs. looking forward to implementing at Magic Mind.

@sahilio "The hard question is no longer 'Can we build this?' it's 'Should we build this?'" really resonated with me.

As AI speeds up development, context and judgment become even more valuable than execution. I like the idea of surfacing the right signals instead of expecting product teams to constantly chase information across tools.

During your beta, what was the most surprising insight Samepage surfaced that product teams didn't even realize they were missing?

@sahilio Congrats on the raise. Man, now I can say I met that Sahil guy way back when.

@ryangilbert Thanks for using the product! Using it to keep a pulse on competitors is actually the onboarding signal we help you set up as a lot of our customers have found that to be a quick win.

It is hard not to read the automated signals generated with my first cup of coffee every morning!

@justinkan Thanks Justin! We're very fortunate to have you as an investor.

This line "staying on top of the constant stream of customer, team, and market signals," is really what this initial product launch is all about, and what our beta customers have been using the product for over the last few months.

Sometimes you don't need another AI agent that claims to do everything for you, while also making you breakfast! In our case, we built the agent for the product person, with product wisdom baked directly into context, so that they don't have to. And what it delivers may sound simple, but is super useful.

@rrhoover The PM job is totally changing, fun to see so many getting closer to code.

A VP of Prod at a security company has a signal that looks at all their gong transcripts from the prior week to pull out feature requests/ideas, then looks at their roadmap in Jira to see what's missing. If anything is missing, it bubbles up and drafts up the new tickets.

Almost all users have some form of competitive intel signals running to pay close attention to specific changes, like if a competitor changes their pricing. Think Google Alerts + an LLM and your context.

A more obvious but valuable use case another customer has just monitors all Github PRs and flags what needs his attention, while also producing recurring release notes so he doesn't have to.

Lastly, we have hookups to all of the major product analytics tools like Mixpanel, Amplitude, and Pendo. Our system is tuned to automatically generate signals for any anomalies in your product performance data for a particular event or a newly launched feature that may need some attention. We actually had a customer catch a dip in one of their licensed branded launches when a signal automatically analyzed his Firebase notifications that were sent to his email!

@sahilio  @rrhoover Smth wild? 🤔 Maybe how many product people have side gigs they're running! They use Samepage almost like an executive assistant to stay up to date on their pet projects. Similar use cases (project tracking, release notes, executive summaries, bug/feature discovery), but "help me manage my side gig" was not a common use case I saw coming.

Most users are focused on the obvious stuff... tasks they were trying to do in Claude but are moving to Samepage because we have a unique take on data and have loaded Samepage with context about product management.

@gagan_biyani Thanks Gagan! Major changes to how product is being developed, so a fun time to be working alongside PMs. Wild to think about this product vs the prototype of a very diff Samepage product over 2 years ago!

@jared_salois Thanks Jared! Great question.

The user can create their own precise signals, which is a great way to just tease out the information they want. You're totally right, if Samepage just creates more noise, which failed.

We use the user's profile, as well as their data sources to generate up to 5 automated signals every morning. These don't persist, and a new batch will be generated the next morning. The user can choose to Edit/Keep any of those automated signals, or discard them. That feedback loop goes directly into our system to improve the signals over time.

We still have a long way to go, but our ambition is to ensure signals drown out the noise.

@foobarfighter It will! We already have teams using the product today, and while we are built for product folks, we've had a fair number of teams from different departments using the product.

We actually have some pretty near collaborative features coming soon - think "shared signals." To keep everyone on the same page.

@foobarfighter You bet. It turns out there are a lot of teams in the company that want to know what is going on with the product, so it's not uncommon for people to invite marketing, sales ops, execs, and more.

@kevinmclane thank you for being a beta customer of ours! Your feedback has been invaluable in developing the product we are launching today. Plenty more coming...next week in fact!

@jaredsf You're a product legend, so that means a lot! It's not the agent that will do the entire product job, but we think one that enables the function well.

@ciaran_lee Thanks Ciaran! We really enjoyed showing you the product earlier this year at the Fin offices in Dublin! You were one of our first calls when we started kicking this idea around years ago. I hope they managed to change up the beers at the Fin bar upstairs, especially considering the incredible acquisition news for you all! 😁

Thanks @rahulvohra ! Coming from someone who lived this at Superhuman, that means a lot. Your PMF work shaped how we think about this, so it's great to hear our effort to "meet teams where they are" comes through.

Even here at Samepage, a small startup, we lean on Pendo for product analytics, Slack for real-time comms, Linear for issues, Cursor for code, Asana for projects, Granola for meeting notes, and probably 20 more tools.

Signals works well because it sits atop the entire stack you already have, rather than competing with it.

Bonus points, Grammarly works like a charm inside Samepage. 😉

@rahulvohra thanks Rahul! I remember we met during your Rapportive days! Reminds me a bit of signals where you all would surface these rich user profiles in the email client. Love what you’re doing at Superhuman/grammarly!

Thanks @ross_sonnabend1! We've had so many people say they start their day reviewing their Daily Signal that we should start selling coffee cups. A @Morning Brew colab perhaps?

@andrasczeizel Great question, Andras.

Have you seen that early episode of Black Mirror where the husband unfortunately passes away, and the widow is able to send all of his messages into a service, and they regrow "him"?

Creepy, but that's the inspiration we took for our Profile we generate for you. Once you link various tools, we go across them to build out a profile of you: who you are, your voice, tone, style, any active goals we can infer like OKRs are general team goals. We then also have pre-built a Product Playbook, with 30+ articles of best practices on things like prioritization frameworks, PRD writing, etc.

All of this builds out a rich profile of who you are as a product person, so that when we go to generate new signals for you in the morning, it uses that context. What's really cool is we took into account that you as a person also change, so you're profile will also continually update accordingly!

@debojyoti452 Thanks Debojyoti! That's exactly what we are doing with Signals. Super simple product that delivers quick, meaningful value through surfacing automated signals every morning at 6am!

@ross_goodhart Thanks Ross! Let us know if you need any help getting started!

@zealous_wiley Thanks Zealous! While AI is a great enabler, and we can collectively build so much more, faster. More is often not better in product land. You can very quickly have a frankenstein product on your hands.

We hope tools like signals can help PMs cut away the fluff and build more of the right stuff.

@jayreno Thanks brotha! Appreciate it coming from another great founder!

@benarent thanks Ben! Appreciate all your early feedback. We think so!

@jdprater You're too kind! But we will do our best, and I learned many of my marketing skills from the legend JD himself.

@jdprater Should we restart the podcast?

@krystalmaria Good question, Krystal! You start with your own Daily Signal feed, but you can choose to share those (one off, or automatically cross-post) directly to destinations like Slack, making them communal!

We are working on a collaboration feature as well, to have a shared stream, where the same signals bubble up to the group in that stream.

@galdayan Appreciate the question. You're right that it's partly the aggregation and partly the PM-specific workflows. After hundreds (thousands?) of interviews with PMs, we kept seeing the same thing: tools like Notion and Linear each automate a slice of the process, but no one owns the whole flow. Then AI tools like Claude, n8n, and ChatGPT can be configured to run automation, but lack the data and context without significant, and I would argue, brittle configuration. l

In other words, sales feedback lives in Gong, product docs in Jira, and strategy in Notion. A ton of conversations still happen in Slack and email. Our approach is twofold. We have a unique way of storing and structuring that data so it's actually accessible to the models, and we've built a full product playbook into the product, with best practices spanning feature discovery, roadmapping, prioritization, and the go-to-market work around it. So it's the aggregation plus the product-specific context that generates useful insights with minimal setup.

Also, there's a free plan, so I would love for you to try it and get your honest take on how we did!

@heidi_grutter Congrats on the launch Heidi!

@prashant_patil14 thanks for the feedback and checking out Polygraph!
The repository graph is updated once a day or on demand when users request it since inter-repo dependencies aren't something that changes super often, it's more of a slow evolution.
The graph of sessions and code changes is updated more regularly, whenever new git changes come in or PRs are created :)
Hope that helps, happy to chat more about it

@wilder_dev thanks for the kind words, Erik!
Polygraph doesn't ship anything here beyond what git already has. So you can make a PR and that might just be unaffected by the new changes.
What polygraph does have though is CI monitoring and skills for helping your agent fix CI across all the different PRs across repos. So if there's a merge conflict, polygraph can help you figure it out and make any further updates that are required after resolving the conflict.

@galdayan 

1. Upon successful onboarding and repositories connection, we assign and schedule indexing workflow that run against the connected repositories whose indexed data is stored as a snapshot at that point in time. Re-index per repository or re-scan entire list of connected repositories can be triggered manually on Polygraph UI.

2. Memory is persisted on the Sessions themselves which are harness agnostic. Harness in which the session started is stored as a metadata for less upfront work like checking for harness plugins/skills and configuration.

@galdayan thanks for checking out the launch!
So the cross-repo part has three parts
- first we have a dep graph and we index all repos semantically so an agent can find relevant repos for its task and include them in the session
- then in order to learn things across multiple repos, polygraph will actually check out the repo locally and delegate subagents to work inside them so we have the actual code in front of us, not just embeddings etc. This also includes any OSS repo btw so you can easily pull them into your sessions
- lastly, after making changes in one or more repos, Polygraph can make PRs across them all, track CI statuses in a single place and coordinate follow ups as well as link npm packages together so you can test out changes from one repo in another one that depends on it

The session memory persists across all agent frameworks, we store normalized versions of the transcripts so you can take a session a colleague started in claude and resume it in codex.

@angelika_dev yes! You can only interact with sessions for which you have access to all the repos.
If all the repos are open-source, you can generate a share link so external ppl can have a look at your session as well (like for repros in bug reports for example).

@ansari_adin it's a full state snapshot including all prompts and responses, sub-agent work, state of the repository(s) but also references to other sessions and their states (like building a hive mind). You can resume the work as if you were running it from the start.

@coly010 Hey Colum!

Max touched on this a little bit in another thread. Right now you can only have access to sessions where you already have permission to access those repos attached to it. You can generate shared linked for external people if all the repos are public for bug repro sharing with maintainers, so maintainers can quickly check the session as well and not blindly re-use the session.

Providing context from a repo without having access to the repo is quite an interesting thought though!

@mfts0 this is insane, I LOVE IT. I didn't think Papermark could get any more awesome!
Fantastic release 👏

@iuliia_sh  @varunvivek thanks for support. currently it's focused on the managing aspect. we have another launch coming where we also give agents access to the dataroom's content.

It would work with local agents as long as they support the MCP protocol

@busmark_w_nika Nikaaaa thanks so much for support!

You are one of the first person I remember we talk marketing on the podcast!

@flxmgdnz Thanks Felix. Yes, that's the next phase for the MCP to give investor's agents access to data rooms they can view

@nevo_david Daaaaaaamn

@nikoatwork niiiiiiceeee

Thanks for support Niko!

@shawn_idrees Very practical tool for remote teams and international friend groups. The interface looks clean and easy to understand.

@shawn_idrees Finding a fair meeting location is usually the hardest part of organizing a meetup. Nice to see a tool dedicated to solving that problem

@shawn_idrees Awesome! Currently it's limited to 4 people but I am considering to add more down the line. What size group would work for you?

@farrukh_butt1 Totally agree

@xichiwoo Thank you so much, glad you like the idea! I will add that :)

@himani_sah1 Thank you 🙏

@henry_habib Thank you! There's no such feature, but maybe worth adding :) For now it's trying to find the best intersection for everyone. I'll make note of this

@patrik_pyoria Thank you! It's currently using the tequila api from kiwi but I am considering to use more APIs comparatively if that's worth the squeeze

@tina_chhabra My favorite comment so far — thank you so much, really appreciate it. Feel free to share with your friends!

@yahav_ohana Love this, thanks so much!

@sunnyjoshi Grass 2.0 looks like a big step up. Congrats on the App Store launch

@sunnyjoshi Congrats on the App Store release! Quick question: for a busy developer who wants to trust an agent to run longer jobs or respond to prompts while they’re away, what safeguards and visibility features does Grass provide to prevent unintended actions, surface important decisions, and let me audit what an agent did after the fact?

@sunnyjoshi The always-on angle solves the real pain, agents that stall because the local machine sleeps or loses context mid-session. Curious whether you handle multiple concurrent agents on the same VM or is it one agent per instance?

@galdayan Fair question, Gal.

If you already have an EC2/Fly/Railway VM + SSH + tmux setup that you like, that absolutely works. Grass isn’t claiming the DIY path is impossible.

The difference is mostly effort and experience: Grass packages the VM, agent setup, mobile access, session visibility, and steering into one product instead of making you stitch it together yourself.

On approvals: today it’s closer to full session visibility + input from your phone.

V2 added the App Store app, a full redesign, faster sessions, Claude Code / Codex / OpenCode support, and a more solid end-to-end experience shaped by real usage.

@super_siddy Thanks Siddhesh :) Look forward to releasing the Android soon.

@divvsaxena we're excited about steering our coding agents from the app.

@dmitrysereda Great launch! What stood out to me wasn't just the unified API, but the shift from "publishing" to enabling complete product workflows. That's a much stronger value proposition for SaaS teams building customer-facing experiences. Looking forward to seeing where you take it.

@jan_heimes thanks mate!

@jan_heimes Thanks, Jan!

@yahav_ohana Thanks for the support, Yahav!

We are big proponents of webhooks and tried to make them as easy to use as possible in Postproxy. They still feel kinda underrated, but once volume grows they are super useful and save a lot of unnecessary polling.

@murilo_bevervanso Thank you, Murilo. Really appreciate this.

Your feedback has been super helpful and we always happy to hear what works and what doesn't.

Thanks for sticking with us 🙏🏼

@murilo_bevervanso Thanks, man! Happy to see you're happy!

@sven_rabe Thanks, Sven! Your feedback is one of the best feedbacks I've ever had. And what you're building is amazing. We feel incredibly proud that Postproxy is a part of your product. Literally after every call I'm astound of what I've just seen.

@sven_rabe Thank you, Sven. This really means a lot.

A lot of what we built got better because of our calls and your feedback. Plus your excitement and energy always gives us a push ) I honestly wish we had more customers like you.

Thanks for being with us since day one.

@sadaf_mahmood1 thank you Sadaf!

@wilder_dev Thanks the comment! Yeah, processing webhooks looks simple until it goes to real production :) To handle spikes and platforms downtime we have a fancy back pressure system in place that takes care of that.

@fberrez1 Thanks for the questions, Florent.

No scraping or scraping-adjacent stuff - we only use official APIs, properly verified and approved flows.

Right now we cover 11 platforms: Instagram, TikTok, LinkedIn, X, YouTube, Facebook, Threads, Pinterest, Bluesky, Telegram, and Google Business. Reddit is coming soon.

Small note on X: because of their pretty aggressive API pricing, we keep X more limited in the base plans and offer pay-as-you-go and bring-your-own-key options for products that need heavier X usage.

As for the analytics, we pull data from the native analytics endpoints and expose it through an API, again, no scraping or guessing ourselve. And we do normalise the structure so the metircs are a bit more consistent across platforms.

@yannikga There's no difference what you post via Postproxy – text, image, carousel, video. The API is absolutely the same for every platform and every format and we take care of what you mentioned. Give it a shot! ;)

Yep, exactly as Denis wrote.

And answering your question of "do I still poll each platform.." - no, there is no need to poll each one. Calling GET /api/posts/:id will return per-platform status. Alternatively (and ideally) you can subscribe to post-related webhooks, i.e. platform_post.published fires when it actually went live or platform_post.failed in case something goes wrong.

@yassine_zeriouh1  The cross-platform iCloud sync is going to make this a daily driver for a lot of people. Congrats! 🚀

@ragsyme At the moment it's available only for Mac, iPad, and iPhone, there's no web, Android, or Windows version at the moment

@anand_thakkar1 Thanks! Normally it's last-write wins for this case, so whoever changed something last wins, unless it's something unrelated, e.g. the agent updating the task status while the human is updating the description of that same task, in that case both are updated at the same time basically :)

@i_sanjay_gautam The MCP server supports pretty much all actions you can do manually as well - so Project creation and editing, Milestone creation and editing, and Task creation and editing. I even let Claude Code plan entire projects with it! :)
Thank you!

@moalhakeem Interesting approach. I like the idea of having newsletters, blogs, landing pages, and lead magnets all connected to the same subscriber base instead of juggling multiple tools. The AI landing page builder is a nice touch too. 🚀

@moalhakeem Congrats on shipping 2.0, Mo! The bottleneck of duct-taping platforms together is so real. Having a single subscriber spine rather than scattering audience data across Mailchimp, Framer, and Linktree makes analytics infinitely more powerful. Bringing enterprise-ready infrastructure and AI capabilities into a unified publishing suite is a smart move for anyone serious about audience growth. Love the clean focus on publishing over designing.

@razan6 Thoughtful read, thank you.

I'd reframe it slightly, though. It's less "analytics over output" and more calm over clutter. Most tools add noise, and noise is what actually stops creators from publishing. So we surface only what matters, so your energy goes into writing.

Underneath it all is one idea: every page exists to move a reader through discover → subscribe → return. Understanding your audience matters, but only in service of that relationship, not producing more for its own sake.

Appreciate you thinking this deeply about it! 🫡

@razan6 We try to see patterns. that's the only way to learn actually. Through our own audience feedback. Usually dashboards are useless. So we introduced the AI agent.

I use it a lot to come up with ideas for my posts, youtube vids and podcast ...etc.

@randa_alsomali thank you so much, this genuinely made our day. 🙏

If anything ever feels confusing or you wish something worked differently, tell us! Feedback like yours is how Nashra gets better.

@benjouss Good question, and since you clearly know this space I'll actually get into it. 🙂

We start everyone on Mailgun's shared pool (but we have a plan to migrate to AWS soon). For the volumes most creators and solopreneurs send at, a well-maintained shared pool with clean auth.

The part we really sweat is authentication. Before a custom domain can send a single campaign, DKIM, SPF, and DMARC all have to verify through Mailgun first, so nothing ever goes out unauthenticated. Until it's verified, we just route through our shared sending domain.

On top of that we watch reputation constantly. Bounce and complaint rates get tracked on a rolling 30-day window plus a burst check so sends, and if things start going sideways sending pauses automatically and the sender gets a heads-up before any real damage is done.

For people sending at serious scale, enterprise plans or as an add-on, we do offer a dedicated IP with a proper warmup ramp, so volume builds up gradually and the IP earns its reputation instead of getting throttled on day one.

So shared pool plus strict auth plus reputation circuit-breakers for most folks, dedicated IP with warmup for the heavy hitters. Happy to dig into any of it, always fun to talk shop with someone who's been through it. 🙂

@benjouss Yeah I remember that phase. I think we just started slowly with Mailgun and built up that sending reputation.
Also, we built 2 or 3 tools to help with spam. For example when people import their .csv lists we scan it for spam. Which is also important since you don't want to charge someone for say 3,000 audience list when in actuality they only have say 1,000 subsribers.


@saleem_hadad can share more..

@ankur_jeswani Yes to all three but they're not three tools stitched together, that's the part I'd push back on a little bit

Most stacks make you run a landing page builder plus an email tool plus a link-in-bio app, and then spend your life syncing them. Nashra is one system: every page, landing, Hub, blog post, shares the same editor, the same subscriber list, and your own domain. A subscribe form isn't a footer add-on; it's the spine. So the whole thing is built around one job: turn a reader into a client, and keep them coming back.

Happy to answer anything specific!

@ankur_jeswani Basically yes, it's the place you send your social media following to. So you keep and nurture the connection.

It's about owning the relationship. We're working on new features all in effort to help you go from followers to clients.

When we say clients we focusing on those selling high end services of expertise. Not digital products.

@prashant_patil14 Thanks, Prashant! 🙏 That's exactly why we built it.

Quick rundown on migration:

• Subscribers — easy CSV import, with tags and custom fields preserved (your list stays yours, always exportable).

• Automations — rebuilt in Nashra, but most can be recreated in minutes.

• Historical analytics — stay on your previous platform; Nashra starts fresh from your first send.

If you're on a paid plan, we also handle the full migration for you at no extra cost—just point us to your setup and we’ll move everything over (posts, subscribers, segments, tags, automations, etc.).

We’re engineers at core, so we’ve focused heavily on making this process clean, and painless.

@prashant_patil14 Hey, so here's what we tryna do. The point is they're not three tools stitched together. It's one subscriber spine, so a follower who reads your blog, joins your newsletter, and lands on your course page is the same tracked person the whole way. That's what turns a follower into a client. Most setups lose that thread across Linktree, Mailchimp, and your site..

@marc_vuit Thank you, Marc!

We're building Nashra for experts globally, not tied to any specific country. That said, we're focused on serving users in markets that are often underserved, with support for 10 languages and a strong RTL experience for Arabic and other RTL users.

haha thank you .. @ibrahim_ewida1 Actually the persona we have in mind when designing is the "retired mom" .. writing should be enjoyable.

@alounpro thank you Ahmed, let's collab soon!

@iqsay Appreciate your support sir!

@gordon_bennett Totally fair question. The important boundary is: Heron is not doing generic TLS decryption on the network, and it is not a MITM/proxy.

There are two capture surfaces. With pcap/live network capture, Heron can parse full LLM payloads only where the traffic is already plaintext, for example behind a TLS terminator, on an inference host, in local/dev traffic, or from a trusted packet source after termination. If all Heron has is encrypted TLS packets on the wire, it can still see transport-level signals like endpoints, timing, sizes, retries, and flow shape, but not prompts, responses, or tool payloads.

The eBPF path is different: on Linux, Heron can attach to the host-side TLS library boundary, e.g. `SSL_read` / `SSL_write`, where the process already sees plaintext before encryption or after decryption. That enables payload reconstruction and process attribution (`pid`, command, executable) without a proxy, but only for processes/containers/runtimes on hosts you are authorized to instrument and for TLS stacks Heron supports.

What remains inaccessible: traffic from hosts we are not running on, processes isolated from our permissions, payloads that never cross an observed boundary, unsupported TLS/protocol paths, and data the provider never returns to the client. So the design is passive and no-proxy, but it is not magic remote TLS breaking.

@vincentwuxi Congrats on shipping v0.7.0!

@kudiff Yes, with one important distinction: Heron does not need changes inside the agent code, but it still needs a capture point you control.

If your agents run on your own cloud infrastructure — VMs, Kubernetes nodes, inference hosts, gateways, or behind a TLS terminator — Heron can work there. You can run it on the relevant host, feed it traffic through cloud-probe/pcap, or use the opt-in eBPF mode on the Linux host where the agent process makes the LLM calls.

If by “cloud-hosted” you mean a fully managed third-party agent where you cannot access the host, network path, TLS boundary, or any log/export stream, Heron cannot observe it from the outside.

So the short version is: cloud infra you control, yes; opaque managed SaaS agents, only if they expose a capture or export point.

@xavier_macia Yes — that is the right caveat.

Today, Heron does not automatically strip PII or secrets before SFT export. The export is explicit, and the resulting JSONL should be treated as a sensitive artifact. If the captured traffic may contain customer data, credentials, or proprietary context, it should go through a redaction/de-identification/review step before being used for training.

The controls we have today are more about exposure reduction: local/self-managed storage, retention policies, stored-body caps, and explicit operator-driven export. First-class redaction policies before export are the right next step, and we are adding that to the roadmap.

If you have a strong view on what the redaction policy should look like — rule-based filters, schema-aware tool-result filtering, allowlists, or review gates — I’d love to capture that in an issue or PR.

@krekeltronics Yes — that is the missing layer we care about.

For agents, the final answer is only one artifact. The more useful debugging trail is what happened before it: model calls, tool calls/results, service paths, timing, loops, failures, and process ownership.

Heron reconstructs that passively from observable LLM/agent traffic. Important boundary: if a local mutation never crosses an observed LLM/tool/API boundary, Heron cannot infer it from the wire alone. But the passive trail still gives teams an independent record of what the agent actually did before it answered.

@angelika_dev You’re absolutely right — this is the core security trade-off of passive evidence.

Heron can reconstruct prompts and responses, which is what makes it useful for debugging, audit, agent-turn reconstruction, and trajectory export. But that also means the Heron store must be treated as highly sensitive infrastructure, not as ordinary logs.

Our intended production model is private/self-hosted deployment inside the same security boundary as the LLM gateway or inference stack. Today that means keeping the API/console private, using retention policies and body caps, and being deliberate about who can access raw payloads or exports.

But that is not the full end-state. For serious production use, this needs redaction before storage, metadata-only capture modes, RBAC for raw payload access, explicit permissions for SFT/trajectory export, and audit logs for viewing/exporting sensitive traces.

The one-click export path is powerful, but it should be governed like access to raw production data. Our goal is for Heron to be a controlled evidence layer — not an ungoverned warehouse of decrypted prompts and customer data.

@ansari_adin Process ID can be distingushed, it is an advantage of ebpf mode. But even there is no ebpf enabled, Heron has the ability to correlate the Agentic turns through signature of the body automagiclly.

@pradyumna6 Great question. Heron is designed to avoid request-path impact: it does not sit between your agent and the model provider, and it does not proxy or mutate requests. It passively observes traffic, so it should not add latency to the live agent path.

That said, it is still a real observer process, so the impact depends on traffic volume, body sizes, capture mode, retention settings, and storage backend. In production we recommend starting with a passive/shadow deployment, tuning retention and body caps, and watching CPU, memory, and disk I/O before expanding coverage.

The main design goal is: if Heron is slow or fails, your agent traffic should keep flowing. Heron may lose observability data under resource pressure, but it should not block the agent itself.

@pradyumna6 Minimum, in real production environment, we record almost 0% cpu usage in 8xB300 production nodes while heron is working very well.

@galdayan you're on the right track: voiceovers and reasoning from AI DJ go deeper into explaining the scene, artists, labels, genres and the story behind them; there is a lot of music on Ninja from niche labels that is nowhere near Spotify, and "the room" is not trapped into your taste profile and is not incentivised by what's viral or charting in mainstream top 100s, so this is a genuine tool for music discovery and crate diggers — i'm a DJ, sound producer, record label owner and music journalist and Ninja keeps introducing me to things i've never heard before. ;)

@matthieu_poitrimolt so glad to hear that, thank you very much! i'm using Ninja for music discovery myself, and i really want people to be able to just have it on background as well as do full-on active listening and go down the rabbit hole of all the ways different tracks, artists, labels and genres connect together. ;)

@martin_mo yay, thanks a mil! there are a few things in place to guarantee high quality of the experience:
1) there is a buffer between the actual HLS stream and what Ninja is generating, it is about 3-5 minutes to account for anything unexpected;
2) the most CPU expensive operation is actually the time-stretched and beat-matched transition between two tracks, so i optimise for this and send the rest of the track as-is to the buffer to speed things up;
3) there is a sensible timeout on calls to LLM and a few guardrails + fallbacks that make sure that if there is no AI capacity to process next track selection, reasoning, voiceover generation or any other real-time operation, there is a graceful fallback to the next best thing that can be done without LLM.

@ranjan_kumar45 yay, hope you're enjoying the vibes — let me know how it goes!

@zinggit what kind of music would you like to discover? personal rooms / streams are on my to-do list for sure ;)

@marc_vuit glad you've asked! yes, i've been DJing and producing music for 15+ years on top of doing music journalism, owning a pocket record label and hosting internet radios, so this project is in this weird intersection between creative and technical spectrums of my interests :)

@nikitacano thats pretty cool!

Quick ones:

- rewriting "the ninja reasons" is something I felt annoyed by during reading
- "Listen Live" upper right could have an animation that something is actually playing (took me 10 mins on the website to see the footer and the live playing indication)
- sing in with google did not work

Questions: "reading the room" how does that work? (What is the room?) [may sign in needed for that]

@joshcoxjcs Congrats on the launch. I work with a network of marketing, SaaS, and AI creators who produce educational content around tools like this. I can help get SendTidings featured in tutorials and workflow videos that show agencies and freelancers how to automate client reporting. Interested in seeing a few creator ideas?

Thank you @krutiparekh16 

At the minute we have a few preset options to choose from, but you can absolutely adjust the opening + closing statements. Put your own branding on it. Connect your domain so emails are routed from your email address.

Defining the template is something we can look at incorporating if you feel it's important to your decision to use our platform?

@noctis06 

Great questions — this is exactly the part worth stress-testing, so let me be specific.

Two people talking over each other / conflicting intent: it doesn't quietly pick a "winner" behind your back. When there's a real disagreement, you can just have it build both directions and actually try each one live, then decide by feel instead of arguing about it in the abstract. And the session replay keeps every intermediate state, so you can scroll back through every form it passed through along the way — nothing gets lost.

Correcting a wrong inference mid-meeting: yep, no need to stop. You just say it — "no, go back to the simpler header," "make it the other version" — and the UI updates live as you talk. Course-correcting by speaking is the loop; there's no restart, no re-prompting.

The code you walk away with: completely platform-independent. It's a normal, complete, genuinely runnable codebase you own — clone it, open it in your own editor, keep iterating. Nothing's tied to us to stay runnable.

Honestly the best way to test the "no-prompts" claim is to run a real session and try to break it — would love to hear how it holds up for you.

@mahir21 

It's closer to your first one — think of it as getting the idea tangible, not shipping the finished product in the meeting.

Most teams (and solo founders) have an idea in their head, but it's invisible — hard to align on something nobody can actually see yet. SayCraft turns that into something you can see and click in minutes, live in the conversation, and when it drifts from what you pictured you just say so and it corrects on the spot. So you're sharpening a fuzzy idea into something concrete — cheaply and fast — and getting the whole team moving in the same direction.

It leans demo/prototype rather than a finished end-to-end product. But the code is real and exportable, so once the idea's clear, you can take it straight toward production.

@noctis06 

Nothing gets discarded.

When it forks two directions, each one is a snapshot you can export — the code and a live link. So across a session you can end up with N snapshots of the different directions you explored; the final product is one codebase + link, but every path you considered stays retrievable. Less "pick one, lose the other," more "keep them all, ship the one you chose."

And it's all in git: the exported repo carries the full commit history — every step of the build is its own commit, so the entire intermediate process is right there in the log to walk, diff, or cherry-pick from in your own editor.

The replay travels too: the whole session — the conversation and the decision trail — is a shareable link, so a teammate who missed the meeting can just open it and walk the entire thing end to end. Here's a real one → https://saycraft.ai/share/By4GWlfmDx6

@xavier_macia Thank you! Glad the idea resonates！

@nuseir_yassin1 Yes!

To be precise about today: everyone's voice can feed the build from wherever they are, but SayCraft isn't a full audio-conferencing tool yet — you don't hear each other through SayCraft itself.

Right now you'd run it alongside your usual call (Meet, Zoom, Teams, etc.) while everyone talks and SayCraft builds.

Native in-app audio — so SayCraft becomes the meeting itself, not just the build layer on top of your call — is high on the roadmap.

@divya_kothari1 It's a bit of a different layer. Claude Code is optimized around an individual developer driving the process through prompts. Most of our work is in everything around generation: turning messy conversation into build intent, applying visual structure, and keeping the feedback loop fast enough that a whole room can react in real time.

@henry_habib 

Good question. A few things keep it in check as projects grow:

It's not freeform under the hood — the templates and the prompts hard-constrain the architecture and structure, so it fills in a known-good skeleton instead of improvising a new pattern each time. And while it's coding mid-meeting, a review agent runs over what just got written and flags problems before they compound — similar in spirit to Claude's design review, but in the loop as it builds rather than after the fact.

Where it holds up best today is the front-end demo/prototype layer; genuinely complex, large-system architecture is what we're expanding into next. Since the output is a clean, readable repo you own, you can always audit it and take the wheel yourself instead of trusting a black box.

Talk is cheap — the harness is built in. 😄 Appreciate the well wishes 🙏

@varunvivek Thanks so much — really appreciate the support. And yeah, that "translating spoken requirements into code without losing context" pain is exactly what got me building this.

Straight answer on the stack: right now it outputs a **React frontend web app, and that's it.** Today the focus is turning a live conversation into something you can *see and click* in real time, so it runs on mock data rather than real persistence. If the team starts talking data structures, it'll model them in the UI — lists, forms, the shapes of things — but it won't scaffold real backend APIs or a database yet.

That's the deliberate v1 scope: the fast "talk → watch it appear" loop for **real-time demos and prototypes**. Real backend / API / schema generation is squarely on the roadmap as it grows from a demo tool into something you'd ship end-to-end. And since the output is a clean, exportable React repo, you can always wire your own backend onto it in your editor in the meantime.

Thanks again for the thoughtful question — exactly the kind of feedback that helps me prioritize what's next ！

@promode_ Looks great and something I'd like to use, but my machine isn't powerful enough to drive local models. Can I use an AI subscription instead?

@promode_ Love the landing page design and the copy! Very clear and neat.

@jacob_spencer2 😄 Honestly not far off, every run already returns a pass/fail verdict and a video recording of what it did, so the browser's basically halfway to filing its own incident report. "Describing tests" was the whole bet: say what done looks like, let the agent figure out the clicks. Thanks Jacob 🙏

@varunvivek Thank Vivek, You can always use cheaper model like Deepseek V4 Flash, Qwen3.5 models to automate scenarios, cost is very low.
https://browserbash.com/math.html

@olli_paloviita @olli_paloviita honest answer: BrowserBash is built on Stagehand , it's the default engine 🙂

Stagehand (by Browserbase) is a TypeScript library you build with in code (act/extract/observe). BrowserBash is the batteries-included CLI layer on top:

• no code, a plain-English objective or a committable *_test.md file
• --agent → NDJSON + exit codes 0/1/2/3 for CI
• --record → video/screenshot/trace of every run
• one --provider flag: local Chrome, CDP, Browserbase, LambdaTest, BrowserStack
• Ollama-first, so it runs on free local models (no API keys)
• a local + cloud dashboard

Library to wire into your own code → Stagehand. Ready-to-run CLI/test-runner → BrowserBash (which uses Stagehand under the hood). Huge respect to the Browserbase team 🙏

@marc_vuit @marc_vuit great question 🙏 The CLI and local runs stay free forever, that's the open-source core, and I want it to stay that way. Monetization is opt-in: a paid tier for keeping your cloud run history + recordings past the free 15-day window. Free runs auto-expire after 15 days; if you want them retained, you upgrade. Team/hosted features are on the roadmap too. The free tier isn't a trick to upsell later it's the actual product.

@krekeltronics 

@patrick_krekelberg spot-on, that's the whole thesis. A BrowserBash objective is the user-level invariant, not a click path: you write "log in and verify the order shows 'Thank you for your order!'", and the agent re-derives the clicks each run. No selector is encoded anywhere, so a selector change can't touch the intent.

The honest caveat is that it's only as good as the invariant you write. "Click checkout" will drift; "verify the order is confirmed" protects intent. The tool nudges you toward asserting outcomes , every run returns a verdict against what you described but writing the right invariant is still on the author. Committable *_test.md files help there: the intent is reviewable in a PR, like code.

@prashant_patil14 There is Plan to keep a diff mechanism also, Visual Checks also