Daniel Braz @dsbraz

The agent orchestration choice is not "model-native or framework." There are three places, not two. In my last piece I drew a line with two ends. On one end, the model orchestrates inside its own reasoning loop. On the other, you build the orchestration in your own code. Anthropic shipped Dynamic Workflows with Opus 4.8. And it lands in the middle. The middle I had left empty. Dynamic Workflows is orchestration that lives in the product runtime. Outside the model. Outside your code. That opens a third control boundary: — Model-native (Kimi Agent Swarm): the boundary sits at the edge of the model. The verifier is just one more agent. — Runtime-managed (Dynamic Workflows): the boundary sits at the edge of the product. The verifier is an external gate you already trusted (the test suite). — You build it (LangGraph and friends): the boundary sits at the edge of your code. The verifier is whatever you encode. The clearest way to feel the difference is to ask each one the same question: how does the system know it got the work right? A note on honesty. I use Claude in production. That is exactly why I need to be clear: there is no independent evaluation yet of how Dynamic Workflows behaves under stress. The swarm numbers have been stress-tested by third parties. The runtime ones have not. Treat the comparison as design intent, not a verdict on reliability. The map gained a point. The advice did not change: choose based on where the control boundary needs to sit. There are just three places to put it now. medium.com/@dsbraz/three-…

Fable 5: @AnthropicAI just turned governance into a product Today Anthropic released Claude Fable 5, its most capable model ever made available to the public. It leads almost every benchmark, and Stripe used it to do in one day what would have taken more than two months of engineering. All true. But that's not what I want to talk about. Anthropic didn't ship one model today. It shipped two. Alongside Fable 5 came Mythos 5. They share the same weights and the same capability. The difference isn't in what the model can do — it's in who gets to use it. Mythos 5 stays restricted to approved partners. Fable 5 is the same engine, but with a safety layer switched on: when you ask something about cybersecurity, biology, or chemistry, it reroutes the question to Opus 4.8 and gives you a more limited answer. In other words, the capability in the headlines belongs to the model that's locked away. What you can actually buy is the version with the brake on. This goes beyond a technical detail. For years, capability and delivery were the same thing: you trained a better model and it went out the door to everyone. Today Anthropic split the two and put a layer in the middle that decides, in real time, which model you get to reach. Governance became the product. The model became a prerequisite. This is what I've been saying: the bottleneck for AI in the enterprise was never the model's capability. It's implementation. For anyone operating in Brazil, this sounds familiar. No serious company under LGPD, Bacen 4658, or ANS rules ever had the model as the hard problem. The hard problem is everything around it: what can be answered, what needs a human in the loop, what needs an audit trail, what can't leave the perimeter. That harness was never an accessory. It was the solution. And Anthropic has just turned it into a product — and is charging twice the price for it. If your strategy depends on having access to the most powerful model, today is a good day to rethink it. The most powerful one isn't for sale. The advantage that lasts isn't in which model you call — it's in the layer that decides how to call it. Capability rents by the token. The harness that separates a pilot from a production system is something no one hands you ready-made through an API.

EDITORIAL | Caso exemplar de ativismo judicial – “Ao transformar uma condenada por omissão gravíssima em vítima, Elizabeth Louro foi mais uma magistrada a expor o perigo de uma Justiça militante”. Leia o texto completo em x.gd/dNiaL via @opiniao_estadao)

EDITORIAL | Lula quebra o Brasil para se reeleger – “Somente neste ano foram 33 medidas, somando a marca de R$ 215 bilhões em aumento de despesas ou redução de receitas. Pelo visto, o governo Lula perdeu a pouca vergonha que ainda tinha”. Leia o texto completo em x.gd/4w5qA

.@McKinsey says the CTO has become a builder. Reorienting the function from managing technology to building market-ready capabilities. I agree. But I want to add a point to this conversation. Almost everything written about building technical capability assumes a product company. A central platform team that builds the reusable foundation product teams consume. In services it's different. Every deal is unique, customized to the client's demand. There's no generic foundation that serves everyone by design. So the question becomes: how does a platform team work in a services company? The answer I've been testing is the forward-deployed model. Instead of a central lab, you advance the engineer who owns the accelerators into the client's problem. They carry two objectives at once. Deliver the solution. And come back with what they learned, to improve the asset. It's the same engineer who builds the tool, takes it to the field, and brings it back better. The asset only evolves because whoever operates it understands the work deeply. Tacit knowledge isn't transferred through documentation. It's transferred through proximity. And here's the part most people get wrong. The differentiator is never the tool. Today it's agents. Tomorrow it'll be something else. Whoever bets on the tool becomes obsolete when the wave turns. The differentiator is the ability to see which wave to ride before the market does — and to operate it first. The tool is the means of the moment. The vision is what lasts. The builder CTO, in a services firm, isn't the one with the best agents. It's the one who keeps the firm a viable partner wave after wave.

Most agent frameworks run one model instance through a loop. It works for sequential tasks. It breaks when the work has parallelizable subproblems that demand different specializations. The standard answer is external orchestration. LangGraph, CrewAI, Python workflows. You design the graph, the state transitions, the retry logic. Full control, engineering cost. Kimi K2.6 makes a different bet. It embeds swarm orchestration inside the model itself. Up to 300 sub-agents in parallel, decomposed and aggregated inside the reasoning loop, not in the code you write. But the point is not the agent ceiling. It is where the control boundary sits. Native orchestration: one API call, one synthesized output, zero infrastructure. And zero ability to audit the coordination logic. External orchestration: full control of the graph, every turn logged and inspectable. The cost is building and maintaining that layer. It is not about which is universally better. Teams that need to explain agent decisions — to auditors, to security reviewers, to the colleague debugging the failure — will find external orchestration's transparency enough to justify the setup. Teams that need to move fast on parallelizable tasks will find the swarm's convenience hard to beat. In our own agent platform we see the same pattern. Native orchestration works well for bounded, parallelizable workflows. External orchestration is necessary when an agent's decision must trace back to a specific business rule. Choose based on where you need control, not on what is newer. medium.com/@dsbraz/kimi-a…

Leiam @fernandoschuler

prompts are technical debt. but not every prompt is the same debt. @sjgoedecke argues prompts are a worse form of technical debt than code. the argument is good: prompts are model-specific, and what worked on GPT-5.4 won't work on GPT-5.5. worse, they decay silently. broken code throws errors. a stale prompt just makes the model a little dumber, and you never notice. his prescription follows the diagnosis: use a third-party tool, leave it unconfigured, avoid MCP and skills, delegate the tuning to teams that re-evaluate prompts every release. i agree with the diagnosis. i disagree with the single conclusion. the mistake is treating "prompt" as one layer. it's two. the first is behavior steering. "think step by step", "you are a senior engineer", "i'll tip you $200 if you get it right". this is pure coupling to the model. this is where the debt sean describes lives. delete it. delegate it. fully agree. the second is theory about the system. concrete facts about the project, domain constraints, architecture decisions, the why behind things. this isn't model tuning. it's Naur's theory written down as text. it doesn't decay when the model changes, because it doesn't talk to the model. it talks about the system. an AGENTS.md full of concrete facts ages at the same speed as the code it describes. slowly. the harness is where these two layers blur. which is exactly why human judgment needs to be more present there, not less. the practical rule: treat behavior steering as high-interest debt — minimize, automate, outsource. treat system theory as code — write it yourself, review it, keep it lean. sean's advice to "write your prompts and delete them whenever you can" holds perfectly for the first layer. for the second, deleting is losing knowledge. the right question isn't "how much prompt do i write". it's "which of these lines talks to the model, and which talks about my system". seangoedecke.com/prompts-are-te…

.@AnthropicAI shipped Opus 4.8 last week. Everyone's talking about the benchmarks. I want to talk about Dynamic Workflows. The model can now coordinate hundreds of parallel subagents — plan the work, fan it out, verify the outputs, report back. Anthropic's own example: codebase-scale migrations across hundreds of thousands of lines, kickoff to merge, with the existing test suite as the bar. Here's why that matters more than another point on a coding eval. For two years we've been bolting orchestration onto models from the outside. Every serious agentic team built the same scaffolding: a planner, a dispatcher, verification loops, state that survives context degradation. That scaffolding is the harness. And the hard-won lesson is that the harness, not the model, was carrying most of the reliability. Dynamic Workflows pulls a chunk of that harness into the runtime. Planning, parallel execution, self-verification — capabilities we hand-rolled — now sit closer to the model itself. That's not a threat to harness engineering. It's a clarification of where the work moves. When the runtime absorbs orchestration, the engineering doesn't disappear — it climbs the stack. The questions get sharper: what do you delegate to the runtime versus keep under explicit control? Where does human judgment stay in the loop on irreversible actions? How do you verify the verifier? The platform still needs a spec, a contract, observability, a way to reason about failure under long-horizon stress. The model getting better at orchestration raises the ceiling on what the platform around it has to be. The teams that win the next year aren't the ones with the cleverest prompt scaffolding. They're the ones who understand which layer of the harness just became commodity — and move their effort up to the layer that didn't. What part of your harness do you think the runtime takes next?

Every team shipping agents to production hits the same question: where is this agent today, and what do we build next? The models we already have answer other questions. Level ladders (L0–L5) give a shared vocabulary. @karpathy's autonomy slider designs the product surface. @OpenAI's levels point to where the technology is heading. All useful — none answers the operational, day-to-day question. That's the problem, because maturity for an agent isn't a single variable. It's the composition of several independent ones. A system can be highly autonomous on one axis and deeply fragile on another — and the gap between "works in a demo" and "works in production" almost always lives in those gaps between axes. In the article I propose six dimensions I've been using for the last eighteen months with product and engineering teams: - Task structure: how decomposable the problem is into stable steps - Verification cost: the single most predictive variable for where agentic patterns succeed - Reversibility and blast radius: what an error touches, and whether it can be undone - Loop speed: Karpathy's metric for partial autonomy - Context persistence: how long context needs to survive, and how reliably - Failure-mode tolerance: what happens, in practice, when the system is wrong It's not a score you aggregate into a single number. It's a profile: six positions, read together. And the pattern that repeats most when I overlay the framework against real agents in production: the gap between what works and what doesn't is rarely the model. It's the harness. The question stops being "what level are we at?" and becomes "which dimension, if we moved it, would change the system the most?" Full article: medium.com/@dsbraz/six-di…

Mathematician solved a problem that had been open for 42 years using ChatGPT. My first instinct was "ok, AI does research-level math now." After listening to the episode, I think that's the wrong read. What @ErnestRyu describes on the OpenAI podcast (with @SebastienBubeck) is a division of labor. @OpenAI's ChatGPT sweeps the literature, suggests connections, sketches proof skeletons. He still does what no model does on its own: pick which problem matters, sniff out when a proof is quietly wrong, decide whether something is deep or just convincing. They touch on a point I think goes well beyond math — the risk of shallow understanding. The model hands you a clean answer, and if you don't have the judgment to check it, you take it. The pairing works because the human knows how to verify. It's not replacement. It's a pair where each side does what it does best. Anyone working with agents in any field will recognize the pattern. 🎧 open.spotify.com/episode/7zijNX…

The agent builder is not the platform. It's an authoring surface on top of it. Sounds like a pedantic distinction — until you try to migrate vendors. When a company buys an "agent builder," it's usually buying a layer 7 wired into someone else's layers 1 through 6 — and inheriting that vendor's choices about runtime, context engineering, tool plane, memory, orchestration, and governance. Usually without realizing those choices were made. In the new piece I unpack the anatomy of an agentic platform into six layers, in the order they load at runtime, and place the agent builder where it actually belongs: at the top, as one surface among several. The core claim: code-first, config-first, visual, and generative — the four authoring surfaces emerging now (@wonderful_ai's Agent Builder, @SierraPlatform's Ghostwriter, and what's coming next) — should all produce the same AgentSpec, consumed by the same runtime. When they don't, you have four disconnected products pretending to be one platform. That's exactly the architectural mistake that makes migration so painful. At @brqdigital we operate our own platform, and these aren't abstractions — they're weekly decisions: what to build, what to buy, and what to own explicitly because owning it is the product. The agent builder, done well, is the last thing you build. Not the first. medium.com/@dsbraz/the-an…

Starting every AI conversation from scratch is a quiet waste. You know the drill: open a new window, paste your style guide, explain who you are, summarize the project, recap what you discussed yesterday. Then do it all again tomorrow. We've all grown tired of this. And that's why some interesting solutions have been popping up. One of them is what @koylanai calls Personal Brain OS: a personal file-based operating system inside a Git repository. What this means in practice: * Progressive disclosure: the AI loads context in layers — general instructions first, then specific modules, only when needed. * Isolated modules: identity, content, knowledge, network, operations, agents. Each gets its own file. * Append-only memory: JSONL logs that only grow, with a defined schema, easy to parse. * Zero database: everything is a text file. Git handles versioning. The result? You stop retelling your story every time you open a prompt. The AI already knows who you are, what you want, and how you think. This reminds me of something I've been saying: the bottleneck in using AI today isn't the model, it's context. The more time you spend reintroducing information, the less time you spend creating. A system like this isn't about having more tools — it's about stopping stating the obvious. His repo is open and works as a practical reference, not just a concept. Worth checking out if you use Codex, Claude Code, Cursor, or any agent that reads local files.

Muratcan Koylan @koylanai

4 months ago

x.com/i/article/2025…

137 862 6K 2.8M 18K

Rings topology

I've been talking about Digital Workers for a while — not as automation with a fancy name, but as agents that hold real positions in real teams. The concept is simple: defined scope, ownership of processes, continuous evolution. What was missing was an implementation that simplified things and let you move fast past the POC. I think @_HermesAgent (from @NousResearch) points in that direction. Today we implement Digital Workers (here at @brqdigital) as custom agents, built one by one. Not because we lack ready-made platforms. But because we need fair governance — knowing exactly what the agent does, why it does it, and how to audit it — and because processes are highly varied. Each role demands custom skills and tailored connector chains. Too much genericity here is a risk, not scale. The problem is that this custom model doesn't scale well. Every new Digital Worker requires engineering from scratch. What interests me about Hermes is that it flips this logic: instead of me writing every skill manually, the agent executes complex tasks, creates skills from experience, improves those skills during use, and persists knowledge across sessions. It retrieves past conversations, summarizes trajectories, and builds an increasingly precise model of who you are — especially when paired with @honchodotdev (from @plasticlabs) for dialectical user modeling. What would this change in practice? Today, when an agent hits a gap in the process, it stops. Someone has to write new code. With this architecture, the agent would create a new skill, test it, refine it. Memory wouldn't be a static database — it would be a living model that enriches with every interaction. This is what separates a DigitalWorker from traditional automation: the ability to evolve within scope without depending on a human to rewrite rules. Hermes runs wherever you need it — $5 VPS, GPU cluster, serverless — and talks to you via Teams, Telegram, Slack, Discord, WhatsApp, Signal, or CLI, all from a single gateway. But the point isn't the stack. It's the behavior it enables: an agent that assumes a function, develops competencies for that function, and improves on its own. We're not there yet. Today it's still custom, one by one, by conscious choice. But the question I ask myself is: what if the next role on our team didn't need a human rewriting rules and connectors every time the process changes?

Agents didn't repeal the laws of software engineering. They intensified them. Wrote about this on Medium. The core idea: AI tools shift the dynamics, but they don't cancel out principles that have governed development for decades. A few things I explored: - Inverted Postel's Law: with agents, you send more context than usual (liberal in what you send), but need to be stricter reviewing what comes back (conservative in what you accept). - Brooks' Law challenged: multiple agents working in parallel can, under certain conditions, speed things up instead of slowing them down — as long as there's robust automated verification. - Conway's Law in a new dimension: each person's prompting style becomes a silent "organizational structure." This can fragment the codebase in ways we're still figuring out how to manage. The point isn't "AI changes everything" or "AI changes nothing." It's that the same laws still apply, only now they operate at different speed and scale. And that brings new problems along with the gains. If you're writing code and experimenting with agents, you'll recognize some of these tensions. Full article: medium.com/@dsbraz/agents…

I tested Kimi. It works. I've been using AI for years. I've seen a lot of things that promise and don't deliver. I tested Kimi with real projects. No demos, no toy prompts. Slides: I fed it a dense document. Expected a summary in boxes. Got a presentation with clear argumentative structure — the model understood the logical progression, not just dumped text into slides. Only needed to adjust when the source document had ambiguous priorities. Agent Swarm: I've seen "multi-agent" that's just sequential calls. Kimi's Swarm actually parallelizes, with agents reviewing each other's work. One caught a data discrepancy I would have missed. Sometimes too conservative in decomposition, but I'll take that over inconsistency. Code: I passed a complex mockup. Got working React, not a skeleton with TODOs. Pointed out a visual discrepancy, it fixed and validated on its own. Works well for UI/UX. For complex state architecture, still needs human input. I still prefer Codex. Claw: Still testing. Want to see how it handles long workflows before I have an opinion. Summary: Not perfect. Has limitations. But better than average at three things: structural inference, agent coordination, and execution fidelity in code. For anyone who's been using AI for a while, it's real evolution, not just hype.

Caught Bender's I/O 2026 talk — Software engineering at the tipping point. Worth a watch. One point that stuck with me: once agents are running internally, every internal API is effectively public. Agents don't negotiate access — if they can get to the data, they will. youtube.com/watch?v=2n41Yj…

In 20 minutes I had an ops agent running on LangSmith Fleet. A week later, it broke. And that's the interesting part of the story. Not because Fleet failed — it did exactly what it promises: OAuth, Calendar/Gmail/Slack integrations, schedule, delivery. All in minutes, no code. But email triage was inconsistent. Drafts came out too generic. The 8 AM cron didn't fit every day. That's the architectural point that matters: when does no-code stop being sufficient — and what do you do next without reinventing OAuth from scratch. I wrote a full case study of the hybrid architecture we ended up running. Fleet as the integration layer, LangGraph for orchestration, LangSmith for observability. With code, decisions, and the three insights that only surfaced once I started reading the traces — including a redundant Gmail search that was consuming 40% of execution time. medium.com/@dsbraz/buildi…