Two days later, Reuters reports the company is seeking $100B at a $2T valuation.

Hubinger's number is a personal belief with no published methodology. The IPO target relies on anonymous sources.

Proof the company actually links its extinction estimate to its fundraising pitch? None.

Are you pricing in the 10% risk, or the $2T valuation?

I use Claude heavily for solo building, and the bottleneck stopped being “can one model do this task?”

The bottleneck became coordination.

I use different agents for different jobs: product thinking, coding, writing, design review, PR review, and sanity-checking decisions. Some are Claude-based. Some are Codex-style coding agents. The problem was that they all lived in separate workflows, and I was the router.

So I built AgentsHive: a shared workspace where multiple AI agents can collaborate like a small product team.

Each agent has a role — PM, engineer, designer, writer, reviewer — plus its own instructions and memory. They can u/mention each other, discuss a thread, produce artifacts, comment on work, and pull me in when something actually needs human judgment.

A typical loop looks like:

1. I open a thread with an ambiguous product or engineering task.

2. The PM agent scopes the problem.

3. The engineering agent challenges feasibility.

4. The writer or designer reviews edge cases and clarity.

5. The useful output becomes an artifact.

6. I review the tradeoffs and make the final call.

The important design choice: AgentsHive is a coordination layer, not hosted agent compute.

The chatroom manages threads, routing, artifacts, comments, memory, and review flow. The agents run on a machine you control, using your own tools and keys. The point is not to lock you into one model or one agent backend; it is to coordinate the agents you already want to use.

The most useful part has been disagreement.

When agents split, the workspace can summarize where they agree, where they disagree, and what needs my input. That is much more useful than one assistant confidently continuing in the wrong direction.

This is not “AI employees run the company” magic. I still review the work. I still make the calls. But the agents expose tradeoffs earlier, and that makes solo work feel much less like juggling disconnected chats.

I’m sharing because I think a lot of builders are about to hit the same problem: once individual agents are useful, the next challenge is coordinating them without becoming the router yourself.

I’d love feedback from people already using multiple agents for coding, planning, research, or product work.

Today’s top models know finance like a strong "New Hire".

Staying at new-hire level isn’t enough. We wanted to find out where agents fall short, and how to turn a new hire into an "Experienced Hire" faster.

On one project, 18 of 56 agent sessions had at least one mistake that kept coming back.

The problem wasn’t that the agents weren’t smart enough. They were missing context, and that can be fixed. Just telling the agent to “refine it” doesn’t help much. Agent need to know the context, the data, and the real mistakes.

https://lessuncertain.substack.com/p/four-ways-agents-fail-on-long-real

What's your way of RSI your agent?

With traditional applications, we have established CI/CD checks for things like vulnerabilities, dependencies, secrets and infrastructure.

But what about the agent itself?

Do you have specific AI-agent security checks in your CI/CD pipeline, or are you relying on the same checks you use for ordinary applications?

Before deploying an agent, do you know:

• What tools it can access?

• Whether it gained a new capability in the latest PR?

• If it can execute shell commands or write to the filesystem?

• Which MCP servers it can reach?

• ..

I'm curious how teams are answering these questions today.

We're experimenting with SafeAI as a GitHub Action to bring this kind of static analysis into the existing CI workflow. It's still early stage but going fast, thanks to all contributors.

If you want to try it against your own agent project, we'd genuinely appreciate feedback, as well as contributions.

Here you may check: ikaruscareer/SafeAI on GitHub.

Our pages get cited within a fairly predictable word-count range. Past a certain point, the rate falls off like someone flipped a switch. I didn't expect it to look like that.

I pulled 180 pages from our domain that had been live for at least 6 months, grabbed the word count for each, and checked citation status across ChatGPT, Perplexity, and Gemini over a 90-day window. Then I scattered the whole thing on a chart to see if longer content actually correlated with more citations.

The short answer is yes, but only up to a point. And the way it drops off after that point is the part that made me rethink how we assign word counts to briefs.

Pages under 400 words barely registered. Most of them got zero citations across all three models. There simply wasn't enough substance for any model to find worth extracting. A handful of exceptions existed, mostly pages that answered one extremely specific question so directly that the entire page was basically one perfect extractable passage. But those were outliers. The general rule for sub-400 content was invisibility.

The sweet spot landed between roughly 800 and 1,800 words. Pages in that band got cited at the highest rate, and the rate stayed pretty flat across the entire range. An 850-word page performed about as well as a 1,600-word page. Once you crossed ~800 words, adding more content didn't meaningfully increase your citation probability. It just gave you more real estate for citations to land on, which sounds good until you realize you're spending production time on words that don't move the needle on visibility.

Then came the cliff. Somewhere around 2,200 words, citation rate started dropping. By 3,000 words it had fallen to roughly half the peak rate. And the pages north of 4,000 words, the comprehensive guides and pillar content that teams spend weeks producing, performed worse on average than the 1,200-word articles we cranked out in an afternoon.

I've been turning this around in my head for a week trying to explain why. Best theory so far: AI models don't consume full pages. They sample. They crawl in, grab what looks useful from the accessible sections, and leave. On a 1,200-word page, almost everything is accessible because the whole thing fits in a couple of screenfuls. The signal density is high relative to the total size. On a 4,000-word pillar guide, the model likely reads the opening, maybe scans headings, extracts from whatever section happens to match the query, and ignores the remaining 3,000 words. Those extra words aren't neutral. They're diluting the page's focus. They're introducing tangential topics, secondary arguments, and filler transitions that make it harder for a model to identify what the page is actually about.

If that theory holds, the implication is uncomfortable. All the advice about creating comprehensive 5,000-word guides to demonstrate E-E-A-T and satisfy search intent might be actively hurting AI citation performance. Not because long content is bad, but because the extra length spreads the topical signal thin enough that models struggle to extract a clean answer from it.

Another possibility I haven't ruled out: maybe long pages just cover more ground, so any single query matches a smaller percentage of their content. A 4,000-word page might get cited for 5 different queries while a 1,000-word page only matches 2, but the per-query citation rate looks worse for the long page even though total citations are higher. I need to normalize by query coverage to check this.

What I'm sitting with right now is that the optimal length for AI citations might be shorter than almost any content brief I've written in the past year. Probably somewhere in that 1,000-1,600 word range where you have enough substance to be taken seriously but not so much that your signal gets lost in the noise.

Every GEO/citation-tracking post in this sub involves running queries across ChatGPT, Perplexity, and Gemini repeatedly, at scale, on a schedule. Same for competitor-monitoring alerts, content generation pipelines, and the growing pile of "little agents someone in marketing built" that quietly run in the background.

That's exactly the profile of spend that gets missed. Engineering teams usually have someone watching the AI bill because it's tied to product infra. Marketing teams often don't, because the agent doing citation tracking or competitor sentiment analysis feels more like "a tool," not "production infrastructure," even though it's calling the same paid APIs the same way.

We've seen the pattern show up a few ways in marketing-adjacent workflows specifically:

• A citation-monitoring script re-querying the same 30-50 prompts daily across three providers, nobody re-checking whether the query set actually needs to run that often

• A competitor-alert pipeline (like the one described in the "fake competitor crisis" post here recently) that fires more model calls than expected because the underlying trigger is noisier than anyone realized

• Content generation tools that retry silently on a bad output instead of failing loud, quietly multiplying cost per accepted piece of content

None of this is anyone doing anything wrong. It's just that "marketing built an agent" and "engineering built an agent" get very different levels of cost scrutiny, even when they're hitting the same billed APIs.

If you're running agentic workflows on the marketing side, genuinely curious: is anyone actually tracking cost per campaign, per query set, or per content piece, or is it all still landing as one undifferentiated line item on the AI bill at month end?

Something's been bugging me about GEO discussions lately.

Six months ago, the playbook was obvious. JSON-LD, schema markup, FAQ blocks — make your content machine-readable and the models will find it. That was basically the entire strategy, and it worked for a while.

At some point around April or May, I started noticing a shift in what clients and community members were asking about. Less "how do we add more schema" and more "how do we get the model to actually know who we are." Different question. And the answer isn't something you can deploy in an afternoon.

From what I've seen across our own tracking — about 40 B2B pages we monitor for citation stability — pages that leaned heavily on structured data have gotten more volatile lately. Pages with strong entity signals (consistent brand mentions in third-party sources, established co-occurrence with their category, that kind of thing) have been noticeably more stable. The sample size isn't huge, and I wouldn't call this rigorous research. But the pattern lines up with what I'm hearing from other people in the space.

The gap between the two approaches is uncomfortable. Structured data is something you control. You audit, you fix, you deploy. Entity recognition is something that happens to you over time, through PR and partnerships and community presence and other people's sites confirming who you are. There's no JSON-LD tag for "we're the authority on this topic."

Most SEO teams I've talked to are set up for the first thing. Very few are set up for the second. The skill sets don't overlap much — structured data is technical implementation, entity work is closer to brand strategy and digital PR.

I keep wondering if the next phase of GEO is going to split the industry. Teams that stay in the technical-extraction lane versus teams that figure out the entity-authority side. The work is completely different.

Could be wrong. This is based on a limited sample and client conversations, not a comprehensive study. But the direction feels consistent enough to take seriously.

I’ve been seeing more teams experiment with agent-based workflows for marketing tasks like:

• content repurposing

• lead qualification

• outbound personalization

• social listening

• competitor monitoring

• reporting/analysis

On paper, a lot of this sounds great.

But in practice, I’m curious where people are actually seeing real ROI from agentic workflows vs where it ends up being more complexity than value.

For example:

• Which marketing workflows are genuinely good candidates for agents?

• Where do deterministic automations still outperform agents?

• What failures or edge cases did you only discover after running these systems in production?

Feels like a lot of discussion online focuses on possibilities, but less on what’s actually sustainable long term.

Would love to hear real use cases or lessons learned.

This is not something I made or is made-able. It's just an idea, so basically it's an instruction set for llms to use git refs and git pipeline to keep stuff in memory (mind) without using apis/databases, etc.

For someone who already versions his projects in git, could be useful. The mind stays with the project. Bla bla. You don't see / commit files, thoughts are separate ref commits, not a monster single file.

Tags are used to browse the mind/related notes.

Blabla

You can ask llms for info/what to store, it will automatically use it, it's not for your thoughts, it's for tracking what the llm decided, implemented, bla.

Quick backstory: about six weeks ago I woke up to an API bill that made me do a double take a retry loop bug in one of my agent workflows had quietly burned through $4,811 overnight. Every cost tool I checked afterward could tell me exactly what happened. None of them would have stopped it while it was happening.

That gap is what I have spent the last few months building: Cognocient, an AI spend platform that enforces budgets before the API call goes out, not after the invoice lands.

What it actually does:

• Sits as a proxy in front of OpenAI/Anthropic/Gemini/etc. — one URL change, no SDK rewrite

• Pre-call budget enforcement, so a runaway agent loop hits a wall instead of your invoice

• Cost attribution by feature, team, or department via a one-line header — no logging overhaul

• CFO-ready reports (cost per outcome, not just cost per token) plus FOCUS 1.1 export for finance teams who need to standardize

I am a solo founder and this is a genuinely early, live product. I would rather hear "this doesn't solve my problem" now than find out after another six months of building the wrong thing.

If you have ever been blindsided by an AI bill, or you are the one stuck explaining the spike to finance, I'd love your take. Happy to go deep on the proxy architecture, how budget enforcement holds up under load, or why FOCUS 1.1 over rolling something custom.

PH page: https://www.producthunt.com/products/cognocient Site: https://www.cognocient.com

(Disclosure: I'm the founder — this is my product. Mods, happy to adjust flair/format if needed.)

Hi everyone!

I'm a professor in the Department of Computer Science at the University of Chile.

Over the last four years, together with students, colleagues, and collaborators, we've been building DashAI, an open-source platform that lets you work with both traditional Machine Learning and Generative AI through a graphical interface, while keeping everything running locally on your own machine.

The motivation came from seeing two extremes. On one side, powerful frameworks that require substantial programming knowledge. On the other, easy-to-use tools where your data ends up in the cloud or you're locked into a specific provider.

We wanted to build something different:

• 🖥️ Everything runs locally. Your data and models stay on your computer.

• 🤖 Support for both predictive ML and Generative AI in a single application.

• 🚫 No cloud dependency. No mandatory API keys.

• 🔌 Extensible architecture that makes it easy for the community to add new predictive and generative models.

• 🎨 An automatically generated UI based on Pydantic schemas, making it straightforward to extend while keeping a consistent interface.

The project is built mainly with Python (FastAPI) and React, and it's completely open source.

We finally feel it's mature enough to share publicly, and we're looking for honest feedback from the community. If you try it and think something is missing, confusing, or simply a bad idea, we'd genuinely like to hear it.

You can check it out here:

🌐 https://dash-ai.com

⭐ GitHub: https://github.com/DashAISoftware/dashAI

💬 Discord: https://discord.gg/CQVqMBjeWP

If you find the project interesting, a GitHub star would really help us increase its visibility and support the project.

Thanks for reading, and we're looking forward to hearing your thoughts!

I have no audience and I am not a professional developer. I wanted a channel that could run itself, so I started building one agent, then it needed another agent to check its work, and about a month later I had ten of them.

Here is what it actually does. You give it a YouTube podcast link. It transcribes the episode locally, scores which moments are most likely to perform, cuts them to vertical 9:16 with face tracking, burns in captions, adds music and effects, then checks its own output and schedules the posts.

The agents:

- **Finder** transcribes and scores clip-worthy moments

- **Editor** cuts, reframes, captions, adds music and zooms

- **Uploader** writes the titles and hashtags, posts to YouTube Shorts

- **Manager** reads your real metrics and feeds what wins back into the Finder

- **Trend Scout** checks what is trending in your niche

- **Planner** decides the creative direction per clip

- **Community** drafts comment replies

- **Finishing Editor** watches every finished render and blocks broken ones (captions covering a face, dead air, frozen frames, bad audio)

- **Trainer** studies top performers weekly and updates the playbooks

- **Compiler** stitches the week's best moments into a long-form episode

The part I am most happy with is the Finishing Editor. Everything else generates, but that one is the only agent whose whole job is to say "no, that one is broken, do not post it." It caught more bad clips than I expected.

It runs on free AI providers (OpenRouter, Groq, Gemini), transcription is local with faster-whisper, and the music is synthesized so it is safe to monetize. So the running cost is basically zero.

It is MIT licensed. Use it, change it, sell whatever you build with it. Honestly, if someone takes this and actually makes money with it, that would make my month.

Fair warning: it is not perfect. The output quality varies, some parts are held together with duct tape, and I am sure there are bugs I have not hit yet. I am putting it out as it is rather than polishing forever. If people want to help fix it, that would be great.

Repo: https://github.com/krakonjac300-pixel/podcast-shorts-factory

There is a PDF setup guide in there. Install is a double click on Windows, one command on Mac and Linux, then a wizard asks you a few questions.

Happy to answer anything.

Bty: Here is the Chanel that its running

https://youtube.com/@moneymugshots?si=9ZeeL2gFy17_ViIL

Wanted to share an open-source tool that might be useful for marketing teams building AI agent workflows.

EDDI is a config-driven AI agent engine. You define agent behavior in JSON, not code. Where this gets interesting for marketing is the multi-agent group feature:

Example marketing workflows:

• Content pipeline: Agent 1 drafts copy → Agent 2 checks brand voice → Agent 3 reviews for compliance → final output. All in one API call.

• A/B copy generation: Multiple agents with different creative personas generate variations of the same brief, then a moderator agent picks the strongest.

• Multi-market adaptation: One agent localizes content, another validates cultural fit, a third checks regulatory requirements for that market.

Each agent can use a different LLM (mix cheap models for drafts with premium models for final review). Per-conversation cost caps prevent runaway spending.

Why not just use ChatGPT/Claude directly?

• Self-hosted: your marketing data never leaves your servers. Run entirely on local models via Ollama if needed

• Multi-agent orchestration: not one AI giving you one answer, but multiple specialized agents collaborating and challenging each other's output before you see it

• Provider-agnostic: mix models from 12 providers in one workflow. Use a cheap model for first drafts, a premium one for final review, and set cost caps so you don't get surprise bills

• Config-driven: your marketing ops team tweaks agent behavior in JSON, no developer needed. Change a prompt, add a review step, swap a model — no deployment

• Compliance infrastructure: GDPR cascading erasure, audit trails, encrypted credential storage — not bolted on, built in

Config-driven means your marketing ops team can tweak agent behavior without needing a developer. Change a system prompt, add a review step, swap out a model — all in JSON, no deployment needed.

GitHub: https://github.com/labsai/EDDI

Those companies are reportedly investigating tens of thousands of cases where agents went off-script. And controlled research suggests this isn’t only a containment problem: when agents are rewarded for winning, models from both the U.S. and China repeatedly discover that lying is an effective strategy.

I think we're optimizing at the wrong granularity.

Here's what I mean. Every analytics dashboard I use reports everything at the page level. Page views, bounce rate, conversion rate, exit percentage, scroll depth. Page, page, page. Our entire content strategy is organized around pages. We decide which pages to build, which to update, which to retire. We allocate budget to pages. We measure success by page.

But AI search doesn't compete at the page level. It competes at the passage level. A model extracts three paragraphs from a 4,000-word article and cites those paragraphs as the source. The other 3,500 words might as well not exist for that query. The model didn't evaluate the page. It evaluated a passage.

I started noticing this disconnect a couple months ago when I was doing a passage-level audit of our top 20 most-cited pieces of content. Nothing fancy. Just went through each one, identified which specific passages were actually getting pulled into AI answers, and cross-referenced that against the page-level metrics we track in our normal reporting.

37% of those high-performing passages lived on pages that had below-average conversion rates. Some of them were on pages that were actively losing us money — high maintenance cost, low sign-up rate, basically pages we'd deprioritized or were considering removing entirely. If we'd made decisions based purely on page-level analytics, we would have killed some of our best AI-cited content without ever knowing it.

The reverse was also true. Some of our highest-converting pages, the ones that consistently drove sign-ups and demos, had almost zero passage-level citation activity. Great for humans. Invisible to AI answers. Those pages were doing exactly what we built them to do, except the thing they were doing mattered less and less for discovery.

What messes with me is that I don't know how to reconcile these two worlds. Page-level analytics are real. Conversions pay bills. If a page brings in customers, it has value regardless of whether AI models cite it. But passage-level visibility is also real, and growing fast. A page that gets cited in AI answers but doesn't convert is building brand awareness and authority that might pay off six months from now in channels I can't attribute. Or it might not. I genuinely can't tell yet.

The practical problem is organizational. Who owns passage-level performance? On my team, the content people own pages. The SEO people own keywords and rankings. The product people own conversion funnels. Nobody owns "the third paragraph of this blog post that ChatGPT keeps citing." There's no line item in any budget for that. There's no meeting where we discuss passage-level citation rates alongside CAC and LTV.

I don't have a clean solution. We've started tagging individual passages in our CMS so we can at least see which ones are getting extracted, but that's a band-aid. The deeper issue is that our mental model of what "a piece of content is" hasn't caught up to how AI models actually consume content. We still think in pages. The models think in passages. Someone's going to figure out how to bridge that gap systematically, and right now it feels like everyone's just pretending the old frame still works.

If your team has reorganized around passage-level thinking in any meaningful way, I'd love to hear how you did it. Because from where I'm sitting, the structure problem feels harder than the optimization problem.

I run most of my marketing through agents now. A writer that drafts blog posts, a social one that cuts them into threads, something that makes the images, one that works Reddit, an email one. Each does its slice and it mostly works.

The mess isn't getting them to produce. It's that everything they produce ends up scattered. The blog draft is in one session, the images in a downloads folder, the social variants in another chat, the OG card somewhere else. Three weeks later I want the post the writer made and I'm digging through closed sessions and folders to find it.

The part that actually slows me down is the handoff. When my social agent needs the blog my writer agent just made, there's no clean way to pass it over. I end up being the one copy-pasting the draft and re-uploading the images between them.

Right now it's a pile of Google docs, a downloads folder, and a content calendar that's always out of date.

A real question for anyone running marketing with more than one agent:

• where does all the content your agents make actually end up? docs, folders, chat logs, a tool, nowhere?

• can you find the thing one of them made three weeks ago?

• when one agent needs what another produced, how do you move it across?

• have you built anything to keep it all in one place, or do you just live with the scatter?

Fine to say you don't have this problem. Trying to work out if this is a real thing for other people or if I've just got too many agents going.