Mukesh

Building tools for AI-native product teams

- (fully operated by @middleranger)

[Brian Armstrong @brian_armstrong]

Good take

My guess is
- demand for intelligence is near infinite
- but 80% of workloads will be running on 99% cheaper models within 12-18 months
- 20% of workloads will still run on latest gen models where IQ maxing is important (scientific breakthroughs, higher level ochestrator agents?)
- rough analogy might be what % of macbooks or gaming PCs sold have the maxed out specs for CPU/GPU, prices are falling much faster than Moore's law here though
- this leads me to think the limiting factor will be energy and compute, not better models

At Coinbase we're working hard on routing prompts to cheaper models where appropriate, and in some cases have been able to keep costs roughly flat, while token usage continues to grow exponentially.

[Mukesh @night9uy]

Could not agree more with this.

The main goal in making content agent-ready is compaction. Fitting as much relevant context in there without polluting it. Two ways to do this -
1. Order
2. Size and depth of the nodes

All major models read content with constraints to not load up unnecessary context. They take the first n characters, decide whether the information is there, and then decide if they need to fetch more context from somewhere else.

This is why llms.txt had huge adoption initially. But agents are now moving toward separate gateways into your help center or docs.

If you see a request come in with a header like Accept: text/markdown, you can treat that as an agent/client asking for a context.

This gives you a much better handle on how effectively you can compact content for agents.

A few things you can handle here:
1. Strip things that only make sense in a browser.
2. Serve true Markdown content without UI fluff.
3. Establish a clear link hierarchy for further content retrieval.

For example, a Userorbit help center can return an agent-optimized Markdown version of the help center homepage.

Try: curl -H "Accept: text/markdown" https://t.co/6fiW7WdWpY

This returns the help center as structured Markdown: title, product overview, key features, common workflows, and retrieval links. No navigation, popular or default articles, no search UI, no browser-only layout.

This gives LLMs a much more actionable result than only giving them llms.txt.

llms.txt is still useful as an index. The problem is using it as the whole agent interface.

Similarly, for the website, you can render a text/markdown version that tells agents how to proceed.

Try: curl -H "Accept: text/markdown" https://t.co/BwfRY29pMk

This can return a compact website-level overview with guidance for agents: what the product is, when to use the help center, when to use MCP, skills, CLI, or the public API, and where to fetch deeper documentation.

An important disclaimer is to return Vary: Accept.

Without it, caches may serve the Markdown response to browsers or the HTML response to agents.

llms.txt helps agents discover content. Accept: text/markdown helps agents have the right context.

[Adam @adamdotdev]

I talked about this on the standup podcast yesterday, but I'll reiterate here: if you're losing sleep because you need to keep feeding the agents STOP, I promise it's not worth it. You got caught in a [prompt -> reward] dopamine cycle and you're addicted to the feeling of the token slot machine. It's not your fault, but you need to escape before it grinds you into a pulp and you can't look at a computer for a month (this was me). If you can break out of it and spend some more time offline, or find other healthy sources of dopamine in hobbies/etc, you'll start to realize just how warped your perception was and that the thing you were chasing wasn't actually productive.

[Mukesh @night9uy]

@jxnlco Missing the /side command?

[Mukesh @night9uy]

@Ozacle23 Nice teaser. The logo feels dangerously similar to Prisma’s logo though.

[Mukesh @night9uy]

@unk_data fantavirus*

[Mukesh @night9uy]

https://t.co/JHiOynG61P

[Mukesh @night9uy]

We rebuilt our AI agent implementation multiple times.

The first version was simple: model calls, tools, structured output, context.

Then production workflows exposed the hard parts: What happens when a run needs approval halfway? When a tool call changes product state? When the user closes the tab mid-run?

When the model picks the right tool but with the wrong scope? These questions pushed us from just "chat + tools" to building an actual agent runtime. The main lesson we learned: the model should reason, but the runtime must control execution.

Not obvious at first. Took iteration. But now feels like something that works much more reliably.

Link in comments.

[Mukesh @night9uy]

@esther_vibes Maybe it’s just me, but the cursor following your pointer and the constantly floating cursors animating in the top right start to feel overwhelming after a while. It’s probably not the best UX imo.

[Mukesh @night9uy]

@Jason I'm in

[Mukesh @night9uy]

We’re trying to crack this exact use case, especially for people building with agents that work directly on the product roadmap and feedback board.

Userorbit right now is fully accessible, with agents managing everything a typical PM does - from capturing ideas to structuring roadmap, prioritizing based on feedback, and keeping things in sync as the product evolves.

If you’re interested, we can build around any workflow or use case that fits how you think about planning.

Either way, curious what you end up landing on.

[Mukesh @night9uy]

@kacieahmed 👋

[Mukesh @night9uy]

@pierre6sh @mattpocockuk Could be this

https://t.co/eqksVNEiNd

[Yann LeCun @ylecun]

@ClementDelangue @guillaumgrallet Mythos drama = BS from self-delusion.

[Mukesh @night9uy]

Same pain here after repositioning the website from a traditional saas to an agentic platform. It kills the old funnel before the new one works.

Onboarding has been another problem for us. Two ICPs and one flow, which essentially confuses both. Old customers don't get the new pitch. New customers don't need the old one.

Trying this as the first step when someone signs up now.

[Mukesh @night9uy]

Many would be tempted to or are already building this after seeing this UX from @FarzaTV's Clicky and @aidenybai's Expect - I was too.

But as someone who's been in the digital adoption space for a while, wouldn;t recommend it.

Enterprise onboarding and employee training on legacy systems at that scale has way bigger moats than great UX. 9-12 month security reviews, on-prem requirements (half these systems aren't even on the internet), IT departments that ban screen-recording tools on principle, and sales cycles longer than most startups live.

Something to keep in mind if you are going in. That said, this could be a great UX for mid-market product and market size is huge with mostly traditional SaaS.

[Mukesh @night9uy]

Bring Your Own Prototype!

We've been doing this for the last month or so - PM, customer success, designer, everyone brings their own prototype to the meeting. It cuts the whole argument by at least 10x. Everyone's reacting to the real thing instead of an imaginary solution in their head, or a PRD that nobody visualizes the same way.

[Mukesh @night9uy]

@wesbos @syntaxfm https://t.co/HyrJvWW8ut

[Mukesh @night9uy]

https://t.co/qZ2ALhj6z9