
founding fde @sandstonehq // ex-blackstone
New York, NY
Joined November 2014
- Tweets84
- Following106
- Followers337
- Likes991
Pinned Tweet
for the last ~2 months i’ve been using an orchestrator within @get_bb_app as a single entrypoint to manage my agents
with the launch of cursor projects and @nicbstme’s viral post about AI feeds, figured it was time to have opus vibe up a hype video for my workflow
at this point there are a lot of ways to have one agent orchestrate a bunch of other agents to do work, but there are a few things an ideal experience needs to solve for:
observability: you should easily be able to talk directly to any of the spawned agents; especially for me as an fde there’s still a decent amount of in-the-loop work where going through the manager would be an unnecessary layer of translation
attention: there’s only so much i can focus on at once. the split in bb feed makes it easy: agents still working are in a separate section, so the ones that actually need responses are clearly emphasized. if you have too many that need you, you can “pause” some to set them aside (bottom section) for later
interaction: support various levels of interaction with the agents - let the manager handle it, talk to the manager directly and have it talk to the agents, reply to the agent directly without leaving the feed (either based on the summary line or expanding the card to see the full most recent message), or fully click into the agent session
there might be other things out there that have all three of these but i’m a tinkerer at heart and constantly customizing so bb’s plugin system makes this seamless, shoutout @sawyerhood for building a great product
legal engineers are one of our biggest assets at @sandstonehq.
they combine legal expertise with engineering capability and can build complex legal features (like redlining and contract drafting) end-to-end, without the usual friction/slowdown that comes with engineer <> lawyer coordination
Looks like everyone is hiring Legal Engineers this week:
Legal Engineer @Microsoft ($278.9K)
Legal Engineer @heyivoai ($320K + equity)
Legal Engineer @Holland_Knight ($245K)
Legal Engineer @EpiqGlobal ($245K)
Legal Engineer @goodwinlaw ($236.5K)
Legal Engineer @harvey ($320K)
Legal Engineer @LexisNexis ($209.7K)
Legal Engineer @WeAreLegora ($325K)
it’s been ~2 months since this banger tweet, I think it’s still super true and it influences how I think about feature development at @sandstonehq
TLDR of the tweet: long-horizon agents are a poor fit for truly novel product work because complete requirements do not exist upfront and present models cannot reliably judge what humans find intuitive, enjoyable, or valuable. they are better at reproducing known forms—like a Call of Duty clone whose requirements have already been absorbed into model weights—than inventing profitable new products alone; novel work needs tight human-agent loops that prototype, test with people, question the approach, and iteratively discover requirements.
especially as an FDE a big part of my job is to talk to the customer and figure out what’s actually needed to solve their pain point; balancing their specific ask with something that’s cohesive with the rest of our product
but for a decent portion of features, once that’s figured out, it is possible to create a complete definition of the requirements upfront
with those requirements, an agent can autonomously plan, build, self-review, and end-to-end verify without my input, only raising things to me when implementation reveals that we should deviate from the requirements for some reason
because of the way AI agents write though, creating that definition in a way that’s easy and reasonable for me to review + iterate on is nontrivial
i’ve been playing with the idea of a “behavior spec”; a Linear document with a set of scenarios (grouped under various headings) that have a descriptive title and three bullets: one for the setup (”before”), one for the action taken, and one describing the state “after” (including a comparison to the current behavior without the feature)
they have to be quite detailed/granular in order to be complete; for a feature i’m currently working on, there are 62 scenarios split across two behavior spec documents. it seems long and daunting, but because the scenarios are written in such a simple way (instructed with a skill) they’re actually quite quick to review, quicker (at least for me) than agent-written documents that are shorter but require more mental leaps / context held in working memory
i leave comments on Linear and iterate with my agent until i agree with the entire document, at which point autonomous implementation begins
note that this on its own isn’t enough for features that have:
- a large amount of net new UI
- complex or ambiguous architecture decisions (things that aren’t clear from following existing codebase conventions + docs)
for the former, aligning first on a figma is super helpful; for the latter a separate document to align on key architecture decisions is usually necessary
opus 5 is a sign that the obsession with “long-horizon agents” in model training is finally backfiring
i don’t like long-horizon agents, and i’ll explain why they fundamentally don’t work
some people will immediately jump out and say “skill issue”. well, show me one profitable business you built with a long-horizon agent working all by itself - i’d love to learn
so far, the only thing they were able to build that’s even interesting enough for people to talk about are those 3d games that are a partial clone of something that already existed
the reason an agent was able to build a working prototype of complex games like call of duty was that a team of humans already figured out all the requirements years ago for how such games should work, what kind of controls are intuitive, what mechanics are fun etc
all those requirements were already absorbed into the model weights, so when you say “build me call of duty” the model already knows the details. its long horizon execution capability can get all the requirements implemented, which i must say is indeed impressive
but now you can see - the value of long horizon execution has a prerequisite of a massive amount of high quality requirements clearly defined upfront. it took a big team of very talented humans months of effort and many iterations to define that for call of duty
now imagine games like call of duty don’t exist yet, how would we use agents to build it for the first time? we can’t say “build me call of duty” any more. and there’s no way we can define months-worth of game design details upfront
we’ll have to build a tiny prototype of the most basic mechanics, play with it, see if it’s fun, then iterate and expand the complexity. even with the smartest humans, that’s how we work towards something great
we don’t need agents to go dark for a long time, spend tens of thousands of dollars worth of tokens, and come back with a product the agent randomly decided to build - try build something truly novel with this and you’ll see it can’t come up with anything that’s actually profitable (i’ll show you why in a bit)
we need a tight feedback loop where we can collaborate with the agent, plan with it, understand what it’s done, question its approach, apply our judgement, give it real world feedback and iteratively arrive at a good outcome
and that’s exactly what opus 5 absolutely suck at. why? i explained it in more depth with my previous post on how RLVR works - RLVR trains the model to generate code that can pass predefined tests in an isolated environment, which is fundamentally incompatible with the idea of having human in the loop. the more we train the models with RLVR to be “long-horizon”, the less they care about talking to humans
ok now - why do they have to talk to humans? why can’t the models iterate and apply judgement by itself?
maybe one day they could, but not today, due to many limitations. two examples -
1. LLMs today can’t “watch a video” yet. they can look through a lot of screenshots, which is extremely inefficient at observing a high fps animated signal. so anything that requires continuous visual attention is something LLMs can’t do very well
2. LLMs don’t truly understand what’s “intuitive” or “pleasant” for humans. they know what’s already proven to be intuitive and pleasant in the past, but if you present a truly novel concept, it can’t predict whether humans will like it accurately
because of those limitations, human judgment is still needed for almost anything valuable. without humans in the loop, agents will only be able to repeat something that already existed, or go in random directions without true understanding of whether it’s building something useful
in summary, long horizon agents assume requirements all exist upfront. they are fundamentally against human in the loop. and they don’t have true judgement for what humans like
that, my friend, is why they don’t work
going to start providing commentary on some of the opinions from my opinions agent (see pinned tweet for more detail) that I feel most strongly about
first installment: AI can make an individual faster while making the organization slower when unedited output transfers verification, compression, and understanding to many downstream readers. generated work is not finished until its author has checked it, cut it to what matters, and can defend every claim; otherwise local productivity is merely displaced cognitive cost.
source: @matheusml terriblesoftware.org/2026/06…
why I agree with this
- I think it’s rude and borderline disrespectful to send someone slop that you haven’t read/reviewed yourself and it takes longer for them to consume than for you to generate
- it’s easy as the producer to think “oh well there are certain parts that are clearly slop / not important / skippable”, but a reader with doesn’t know what you actually agree with and has less context so it’ll take even longer for them than it would have for you to review it
- I agree with @kunchenguid that anything that’s one-shotted is by definition slop, so unless your agent had some really unique / hard-to-replicate context before you one-shotted it, honestly more useful to send someone the prompt you used
size of impact
- this is mostly likely to have a negative organization-wide impact on productivity/output at large, interconnected organizations that move fast but are still ramping up on AI and don’t have a strong culture around it. the size also makes a strong culture harder to create and spread
- for more isolated teams (<3-6 people working on a given project/product area and can work relatively independently, even if part of a larger group) that don’t move as fast (decisions on what work gets done goes through layers of management/bureaucracy), the volume isn’t high enough for it to be more than a personal inconvenience. speaking from experience based on my last job
- for highly AI-native small to medium teams (e.g. startup) it can be a problem if unaddressed but much more likely to be addressed culturally; at @sandstonehq we’ve explicitly discussed this for the eng team and slop is minimized + transparently communicated
one note is that none of this applies to content intended to be consumed by an agent rather than a human; i’m starting to see more of “attached a markdown doc with more detail for your agent to read” or similar, which is an interesting multiplayer use case
Ryan Brown retweeted
shoutout @c_amataa for building the best slack and salesforce experience on the planet
Replying to @sandstonehq
@Sandstonehq brings your legal team's workflows into Slack. intake, triage, drafting, redlining, all in real time. @mention it and it asks the right questions, pulling from your business context.
Tag: @Sandstonehq👇 sforce.co/3TG1DHV
Replying to @sandstonehq
@Sandstonehq brings your legal team's workflows into Slack. intake, triage, drafting, redlining, all in real time. @mention it and it asks the right questions, pulling from your business context.
Tag: @Sandstonehq👇 sforce.co/3TG1DHV
this is great, a better version of what I’ve had in my personal AGENTS.md for a while- it’s super annoying when coding agents apply defensiveness / backcompat to greenfield side projects
This AGENTS.md fixes the 𝘁𝗵𝗿𝗲𝗲 𝗺𝗼𝘀𝘁 𝗮𝗻𝗻𝗼𝘆𝗶𝗻𝗴 𝗵𝗮𝗯𝗶𝘁𝘀 of Codex and Claude Code: writing backward-compatible code for a project nobody uses yet, never deleting old code and docs it no longer needs, and adding a pile of tests just to change a button color.
After using them every day for months, the lines I'd want in there from day one are the ones at the top: if the project has no real users yet, skip compatibility and migrations, and go straight to 𝘁𝗵𝗲 𝘀𝗶𝗺𝗽𝗹𝗲𝘀𝘁 𝗰𝗼𝗱𝗲 𝘁𝗵𝗮𝘁 𝘄𝗼𝗿𝗸𝘀.
Then a four-step loop: docs first → tests → smallest implementation → clean up.
Copy and paste it into your AGENTS.md 👇
inspired by @spakhm for the format + emphasizing the lower friction of tweet vs. blog and @kunchenguid for the inspiration for OPINIONS.md, sharing my process for generating opinions and a selected few of my favorites:
process
- kun chen’s opinions.md agent takes in his tweets / blog posts as input; i don’t tweet or blog nearly enough and half of the time they’re about side projects anyways, so that wouldn’t be a valid source of opinions
- instead i leveraged Readwise, which is what i use to centralize my reading + storing of content from substack, twitter, web blogs, etc.
- i highlight interesting or important snippets on some articles when it feels worth saving for later; the agent runs on Railway on a weekly cron, receives the highlights, my existing opinions, and can read more into each article if needed
- since these aren’t things i wrote myself i may not agree with them, so the agent sends me telegram messages with opinion proposals that i can accept, reject, or reply with feedback. it can revise existing opinions or attach new evidence that supports existing opinions
- this ended up being a super interesting project on agent and eval engineering + evolution; what defines a good opinion? what kinds of mistakes (false positive vs. negatives) do i care about more? how can i make the agent consistent on something inherently qualitative?
opinions
- people remain accountable for AI-generated artifacts they ship and should understand them well enough to defend them under questioning; review culture should give harsh, specific pushback when output crosses into slop.
- AI makes volition more important, not less. the people who benefit most will actively wrestle with it to strengthen their own capabilities and accomplish more, rather than using it merely to avoid effort. education should therefore prioritize the desire to work hard, learn, and put abundant machine knowledge to creative use.
- a vertical AI startup can defend itself against foundation-model labs by obsessing over a narrow set of real customer workflows. continuously turning those workflows into benchmarks and product improvements creates a learning loop the labs are unlikely to match because the vertical is the startup’s whole business, not the lab’s main quest.
- as AI makes products easier to imitate and more superficially similar, specialized product taste becomes more defensible. taste comes from deep understanding of a particular user’s work and compounds across many small choices in the UX, model, defaults, and interaction; individual pieces can be copied more easily than the coherent whole.
these last two are (part of) why i’m so bullish on @sandstonehq
and these four are a small subset of the 84 total opinions as of today; the list keeps growing every week, the full thing is on my website/github
ARC-AGI-3 from @arcprize has gotten a lot of attention recently with many near-perfect scores
I consolidated the results from the last six weeks; they reveal an interesting spectrum in cost and how much ARC-specific strategy each harness encodes
currently, all harnesses (including the simpler pro-long and potentially prime agent) require specific instructions on how to approach ARC. a human doesn't.
humans can quickly + easily figure out the rules and solve the games (which is why action efficiency relative to humans is what the benchmark is scored on)
so obviously ARC doesn't quite measure AGI, but I think there are two interesting frontiers left to be broken on the arc-agi-3 games:
1 - a harness as or more general than pro-long achieving 99%+ for a reasonable cost
2 - a harness with no specialization and no instruction beyond "you're being given a 64x64 game and your goal is to figure out the rules + solve it" achieving 95%+
chart methodology: I selected the best performing run for each harness; for cost I either used the reported cost or calculated it myself (e.g. codex subscription used, chart-only)
full detail: github.com/ryanbbrown/Retrod…
the level of specialization differs across harnesses:
highly specialized harnesses (baseline1, Tycho, Schema) saturate the benchmark (99%+) but are expensive ($2500+)
Retrodict is the exception to the cost rule, achieving 99.9% for only $654
pro-long from @alexisfox and team is more general, with a small (~400 word) system prompt and ARC-specific logic coming in through what gets appended to the text log; it comes close on performance but is a small step below, with 94.6% pass@1 and 97.4% best@2
prime agent from @PrimeIntellect says the task prompt was its only ARC-specific change, but the exact prompt and setup are unreleased
if the prompt is similarly minimal as pro-long's, then the 95.5% for ~$944 likely represents a new point on the cost/performance/specialization tradeoff
however, if the prompt is basically just text encoding/instruction of the more specialized 99%+ harnesses, it is still a new and unique datapoint but isn't quite as interesting
at least on ARC-AGI-3, the best demonstrated cost/performance tradeoff still comes from a specialized harness
that may be the natural result for a fixed benchmark with inspectable verification and traces: you can encode recurring lessons into the harness one time, rather than having a general agent rediscover it on every game
the full public set of games ARC-AGI-3 was released over 4 months ago, why the heightened focus right now?
my guess is the new generation of models: Retrodict, the agent I built, became viable because gpt 5.6 sol provided significantly better performance at a much lower cost than gpt 5.5
github.com/ryanbbrown/Retrod…
nvidia's NOOA had a similar story, using the same harness performance jumped from 50.2% with gpt 5.5 to 85.1% with sol
i got tired of the bloat (especially pronounced for non-coding use cases) which is exactly why i built my own truly minimal agent framework, ThinHarness: github.com/ryanbbrown/thinha…
One trend happening right now is that devs are only adding to harnesses (system prompt text, skills, tools). it’s not surprising that on the 6+ month time scale when new models release, costs go up and accuracy impacts are unclear. I am however surprised that this trend is happening with the frontier LLM providers!
I've been working for a couple months on ThinHarness, an open-source Python framework for purpose-built AI agents (<8k LOC).
It implements the features that are tedious to rebuild and generalize well: filesystem tools, structured output, retries, approvals, subagents, MCP, skills, streaming, and tracing. Your app owns the rest.
ThinHarness is small but powerful: On a LongMemEval-V2 subset, it edged out a task-tuned Codex harness (74.0% vs 72.4%) using ~46% fewer tokens and only built-in tools.
Would love feedback from anyone building agent workflows, check it out: github.com/ryanbbrown/thinha…
this quote from @simonw on the heavybit podcast yesterday was spot-on:
"So I realized what I value more than the quality of the tests and documentation is that I want somebody to have used the thing. If you’ve got a vibe coded thing which you have used every day for the past two weeks, that’s much more valuable to me than something that you’ve just spat out and hardly even exercised."
i frequently try out niche github projects and sometimes there are some glaring holes that make me think the creator never actually used it
might explore adding USAGE.md and usage.jsonl to some of my side projects













