<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>SageOx Blog</title>
<subtitle>Insights on agentic engineering, team context, and building with AI coworkers.</subtitle>
<link href="feed_xml.html" rel="self" type="application/atom+xml" />
<link href="blog.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog</id>
<updated>2026-06-01T00:00:00.000Z</updated>
<icon>https://sageox.ai/favicon.ico</icon>
<entry>
<title>RIP Tech Interviews, Oxy Will Not Miss You</title>
<link href="blog/rip-tech-interviews.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/rip-tech-interviews</id>
<published>2026-06-01T00:00:00.000Z</published>
<updated>2026-06-01T00:00:00.000Z</updated>
<summary>Every engineer we&apos;ve invited to a work-trial would have been a confident &apos;hire&apos; under the methods I trusted my whole career. Only two of six clicked. This is what the trials taught us about finding who actually thrives in the A.D. era — and why we let people find that out for themselves.</summary>
<content type="html"><![CDATA[
At SageOx we believe the technical skills you earned in the **B.C. era — Before Claude — are only loosely correlated with success in the A.D. era.** The whiteboard algorithm, the four-hour system-design ritual, the take-home graded on idioms a model now writes for free: cargo cults, every one of them — going the way of bloodletting, a practice we performed with total confidence for two thousand years before anyone bothered to check whether it worked.

So we don't run technical interviews. Like Steve Yegge — who [poured one out for the technical interview](https://steve-yegge.medium.com/the-last-technical-interview-bc13ddcf4564) after 35 years of giving them — we believe in **work-trials.** Come build with us for a week. Ship something real, alongside the team, in the way the team actually works.

**Every single engineer we've invited to a trial in 2026 would have been a confident HIRE under the methods I trusted my entire career.** Résumé, references, a sharp interview loop — by every old instrument, each of them was a yes. And these weren't methods I held lightly: Ryan and I were Bar Raisers in the Amazon era Steve writes about — we ran the loops, calibrated the bar, held the veto on hires. So I want to be precise about what I'm claiming, because it is *not* that the people who don't join us fall short — the uncomfortable part is that my most calibrated judgment said yes to all of them.

We've run six trials. Two clicked. If those instruments were any good, that number should be close to six. The gap between what they predicted and what the week actually revealed is the whole subject of this post.

## The Instruments Were Always Broken

Daniel Kahneman named the bias that keeps the technical interview alive. He called it the [illusion of validity](https://en.wikipedia.org/wiki/Illusion_of_validity). Evaluating Israeli Army officer candidates, he and his colleagues made confident predictions about who would lead — and the predictions were worthless against what the recruits actually did. The eerie part wasn't the failure. It was that knowing about the failure didn't dent their confidence:

> The statistical evidence of our failure should have shaken our confidence in our judgments of particular candidates, but it did not. It should also have caused us to moderate our predictions, but it did not.

That's every hiring instrument I've ever used. They *feel* predictive. They produce a confident HIRE. And the confidence survives even when the prediction misses, because we almost never get to watch the counterfactual.

## What Six Trials Taught Us

The real surprise was *how fast the fit revealed itself — in both directions* — usually before anyone had to say a word.

Twice it was an obvious, mutual yes within days. Galex and Emory each clicked into the way we work so naturally that the "decision" had basically made itself by mid-week — for them as much as for us. You could watch the energy compounding. Nobody felt evaluated; we were just building, and it was plainly working.

Other times the week pointed the other way, just as clearly — sometimes that was the candidate's read, and once or twice it was ours. One engineer realized on the morning of day two that this wasn't the world she wanted to be in right now, and said so — clear-eyed, no drama, gone by lunch. Another wrote to me after his week, and his note has stayed with me:

> I loved the week with the team and had a lot of cool moments building things and seeing what the team is able to ship in a crazy short time — this was eye opening. We're in a new world. It's going to change the way I build forever. So thank you for the chance to watch you work.
>
> ...it's such a different way of working that I can't leverage what I've learned/experienced in my career and that feels like too big a change.

There is no failure anywhere in that. He showed up in good faith, gave real energy, shipped real code, and read his own fit honestly — which is exactly what the week is for. I wrote back: "no harm, no foul." From our first conversation I'd told him these are revolutionary times and the only way to get a read on them is to do exactly what he did — try things out. That's the kind of *no* a real week of work produces: graceful, mutual, and more informative for both sides.

The trial isn't a filter we apply *to* people. It's a shared experience that lets everyone — us included — feel the fit instead of guessing at it.

## The Wooden Racket Problem

It helps to remember that the reluctance is rational. In the late 1970s tennis was switching from wood to oversize graphite, and the players who legitimized the new frames were not the champions. Björn Borg, Jimmy Connors, and John McEnroe stayed on wood long after better rackets existed. It was Pam Shriver — sixteen, unseeded, swinging a Prince oversize — who reached the 1978 US Open final and showed the rest of the sport what the new equipment could do. [Researchers who later modeled the racket industry](https://core.ac.uk/download/pdf/132271095.pdf) found this was the rule, not the exception: challengers adopt the disruption first; the incumbents, with the most invested in the old technique, adopt last.

That's [Clayton Christensen's innovator's dilemma](https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma) in tennis whites, and the incumbent isn't foolish — he's *rationally* defending a winning position. A well-paid software engineer in 2026 is holding a beautifully strung wooden racket. *"I can't leverage what I've learned and that feels like too big a change"* is the dilemma stated perfectly — and it's a real cost that only the person holding the racket can price.

So we don't ask anyone to be braver than the moment deserves. We just offer a low-stakes week to actually swing the new racket and feel how it sits in the hand. Some people light up. Some don't. Both are useful answers.

## "Let's Sit Out 2026"

There's a quieter version of the same instinct: *things are changing too fast — let it settle, and I'll re-enter when the dust does.*

Here's what I worry about. This is a cognitive revolution, and revolutions like this tend to compound. The gap between someone building with agents every day and someone watching from the sidelines may not hold steady while you wait — my fear is that it widens, with every model release. Sitting out feels conservative. I suspect it's closer to the riskiest move on the board, because as best I can tell the longer you wait the harder the catch-up, not easier. I could be wrong about how steep the slope is. I'd be surprised if I'm wrong about the direction.

## We Ran the Trial on Ourselves

I'm not asking anyone to do something Ryan and I didn't do first. From May to December 2025 — eight months — the two of us interned. No pay, no benefits, no title. We'd had long careers; we threw ourselves back into the deep end to feel the new way of working in our hands instead of reading about it. We had two or three colleagues at the time who looked at that and saw something well outside their comfort zone. They weren't wrong about the discomfort.

The obvious objection: *sure, but you're founders — you had the upside to justify five unpaid months.* Completely fair. We're not pretending our stint and an employee's are the same bet, and that asymmetry is exactly why we'd never ask a hire for five months of anything. The ask is a single, bounded week — small enough to be reasonable for someone with a job and a mortgage, long enough to feel whether the work lights you up.

What that stretch taught me — or what I think it taught me, on a sample of two and change — is that the trait that seems to predict who thrives in the A.D. era isn't seniority or pedigree. My best guess is that it's an appetite for novelty and ingenuity *for their own sake*.

## Proposed Trial Criteria

These are a draft — a work in progress like everything else here — and the goal is plain: get to a better conversion than two in six. Some of them already earn their keep *before* a trial ever starts, by helping people self-select out or by shaping who we invite in the first place.

- **Be Claude Pilled.** By June 2026, this is a must, not a nice-to-have. If agentic coding isn't already part of your daily practice, a week with us will be a firehose.
- **Has spent real time in our product.** Not a glance — actually poked at it.
- **A prior track record of excellence.** We all know what that looks like.
- **Evidence of a pioneer spirit.** Doesn't default to the beaten path; willing to take calculated risks — in work, and in life.
- **Willing to come in and cook with us for 3–5 days.** In person, shoulder to shoulder. That's the trial.

I expect this list to be wrong in places and to keep changing. But it's a start, and it's honest about what we're actually selecting for.

The technical interview had a long run. Rest in peace — Oxy will not miss you.

---

*Curious whether the SageOx way fits you? We're hiring our first ten. [hi@sageox.ai](mailto:hi@sageox.ai).*
]]></content>
<author><name>Ajit Banerjee</name></author>
<category term="insights" />
</entry>
<entry>
<title>The Future of Software: Steve Yegge and Ajit Banerjee in Conversation</title>
<link href="blog/the-future-of-software-yegge-banerjee.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/the-future-of-software-yegge-banerjee</id>
<published>2026-06-01T00:00:00.000Z</published>
<updated>2026-06-01T00:00:00.000Z</updated>
<summary>Steve Yegge and Ajit Banerjee on AI literacy cohorts, the death of job titles, why human connection is getting more important — not less — and what it actually means to &apos;cook&apos; with AI. Hosted by AI House Seattle, May 20, 2026.</summary>
<content type="html"><![CDATA[
On May 20, 2026, AI House Seattle hosted a fireside chat with two people who have been thinking about software and teams as long as anyone in the industry: [Steve Yegge](https://www.linkedin.com/in/steveyegge/) — prolific engineering writer, creator of [Beads](https://github.com/steveyegge/beads) and Gastown, author of *Vibe Coding* — and Ajit Banerjee, co-founder and CEO of SageOx. I had the pleasure of moderating.

The conversation ranged from how Steve and Ajit each discovered agentic engineering, to the three AI literacy cohorts Netflix has data on, to what roles actually survive in a world where code is free. Below is the full transcript, lightly edited for readability.

### Transcript

**Milkana:** I would like to introduce Steve and Ajit — probably many people already know them, but they have been around the Seattle tech area for a very long time. They worked together way back when, maybe two decades ago, in early Amazon days. Since then, Steve has spent time at Google. He is a very prolific writer who has been writing well before AI about tech culture and languages. More recently, he has become one of the leading voices of the AI revolution. He wrote the book on vibe coding. He is also the creator of Beads and Gastown. We are so lucky to have him. There was one week last month when I opened the New York Times and Steve was profiled, and then there was an HBR article, and then he won a Tim O'Reilly award — all within a few days.

We also have Ajit Banerjee, someone I'm very lucky to work with here at SageOx. This is not his first rodeo — his fourth startup, with several exits before. His most recent company before SageOx was Zed Hub, acquired by Hugging Face. The technology he built is currently powering over 100 petabytes of data used by millions of developers daily. He made rounds at Meta and Apple and was on the very original EBS team at AWS.

Steve, what was your leap into AI? How did you get started?

**Steve:** How did I get into AI — the same way you all did. November 2022, ChatGPT came out and I immediately tried to write Emacs code. And it kind of did. And I was like, *whoa.*

The pivot points from there: realizing it was viable, realizing I was racing ahead of everybody else. Everyone in the enterprise was focused on completions and I was doing chat. Then I got into agents and everyone else was using Cursor and chat. Then I got into multi-agent and everyone else was still on Cursor, still on Copilot.

I was head of engineering at Sourcegraph when all this went down — a code search company, which is still a pretty good business because we're generating 10 times more code than we used to. But AI dropped right then and we had to pivot to be an AI company. We built a coding assistant. And I'll be honest — Claude Code was such a good idea. I was so close to it. I was talking to my boss about it at Sourcegraph at the time. They needed to use tools, they needed to get the human out of the loop. But I'm old school and I grew up when bytes mattered. I'm a little too frugal to have thought of an idea as brazenly token-hungry as Claude Code.

Every time we change the form factor — completions to chat, chat to agents, agents to orchestrators running bunches of agents — it's because we find a way to spend tokens ten times faster. Each form factor shift is roughly a 10x token burn increase. That's the story.

**Milkana:** Ajit, what was your path into agentic engineering?

**Ajit:** The first thing I want to say is that I have a term now: BC — Before Claude. Nothing about my life before December 2025 is relevant to my intellectual thinking anymore. I'm this quiet infrastructure guy. I would never be in front of 200 people next to a legend like Steve unless this world had changed. We challenge each other on our team: "Is that statement BC or AD? You can't build that the old way — are you sure? Or are you scared of something?" This framing has been a big unlock.

Ryan and I have worked with Steve way back in our Amazon days — really, really old Amazon parts, 2003. But what we've been focused on at SageOx from the beginning is teams. We believe software and knowledge work always will be a team sport.

One thing that's going to make everyone uncomfortable: what we've found is that for a team to cook the way we are cooking, it requires a level of radical transparency that creates incredibly uncomfortable experiences. When I told Milkana she was joining us and we'd be livestreaming all our decisions, her reaction was literally to cover her stomach. That is the level of discomfort one feels at that level of openness. Steve has been telling us the same thing — actually putting your dirty laundry out while you're thinking, sharing it with your team, is essential.

I want to be very clear: I've been having the time of my life. We raised our seed at $15 million. I left Hugging Face in May of last year and walked away from three years of vesting. And the energy we have on our team is something else to watch. There are days when Milkana has tears talking about what we're building. There are days where we are like kids in a Lego store. For all the talk of AI efficiency, not many people talk about the *joy* — and I want that said loud.

**Milkana:** Let's double-click on what it means to work in this AI space. What's the SageOx way of working?

**Ajit:** We have two small rooms in this space, and you'd think we'd keep teams separate across those two rooms because they're small and we're packed in. But we actually sit right next to each other at this distance, and Ryan sits next to me and Galex sits next to me.

The delight happens when we're working. We don't talk much — we have our standup and then go into deep concentration. And then suddenly something shows up, like a little drop of wisdom from the side: "Hey, I figured out you're working on the V1 of this codebase — there's actually a V2 and here's how it connects." Because we have all these agents murmuring to each other. The first time it happens, it's real. It's like the Hunger Games when the parachute drops in with a little idea. And then you get addicted to this level of flow.

I think there have always been great teams that could live at this level — completing each other's thoughts, making no-look passes. This technology, because it speeds everything up, allows many more teams to have this experience.

**Milkana:** I should add some context for those not as familiar with SageOx. When Ajit describes those murmurs — they happen from other agents working on the team, emitting updates on what they're working on. That's how in real time you see what's happening across the team, both humans and agents. I don't think Ajit gave enough credit to the fact that yes, Claude is amazing, but we've built a lot of these experiences to make those connections happen in real time.

Steve, how do you work? You have a fleet of agents. What does your day look like?

**Steve:** First, quick show of hands — who uses one or two agents throughout the work day? Okay. Who uses three or four or more? Okay, we've got a pretty AI-literate audience here.

The way I work: I made Beads, and that was the way I worked. Then Gastown doubles down on that. Gastown is all about swarming. The basic workflow: create work, do the work, create more work, do the work. You do a design, work it out, file a bunch of Beads for an implementation plan, review it. You've just created a bunch of work. Then you say, swarm it — and it grinds away. I love it.

But I encourage people to write their own orchestrators. As soon as you get to about four agents, it gets really hard to keep track of which one is working on which thing. You accidentally give a big project to the wrong agent, it tries to make you happy by doing it in the wrong place, and then you've got cleanup. The cognitive overhead is high. When you get into that space, you start building your own tooling, and I think that's where a lot of people are right now.

**Milkana:** Can you talk about the cognitive overload? How do you stay sane?

**Steve:** Right after I published *Vibe Maintainer* and put out Beads and Gastown — I was getting hammered by 50 to 100 pull requests a day. I did the same thing I always do: I got help. I turned it over to a bunch of people who are maintaining it now, and I was able to step back.

And what I realized was that I was racing way too far ahead of everyone. I was blocked on adoption — on AI literacy. So let me share a story from Ezra Savard at Netflix. He's been training everyone at Netflix on AI for three years. They actually teach our book — the vibe coding book — in their program. They do vibe coding in cohorts. After a lot of data-driven analysis, they found there are basically three cohorts of AI literacy.

Cohort zero: non-users. They chat occasionally but spend essentially zero tokens. There are probably none of them in this room.

Cohort one: single-agent synchronous throughout the work day, roughly 4 million tokens per day. This is the first level of AI literacy, and it's the baseline your whole company needs to reach before you can even think about pivoting. And here's the incredible finding: you can get people from cohort zero to cohort one in four and a half hours — if you bring their manager and their team, they're on the clock, they bring their actual work with them, they have a good trainer, and there are no more than 6 to 10 people in the session. All of those have to be true. But then five hours later, they get it. Their mind is open.

Cohort two: the only one that really matters. 12 to 15 million tokens a day. This is when you finally trust your agent enough to let it go work by itself — you've spun up multiple agents and you're just reviewing their outputs. You are officially trainer-level good with AI. Any token spend above that is vanity metrics. And you can get people from cohort one to cohort two with just one more class in the same format, a couple months later.

So the training problem is totally solvable. But there's also a culture problem. Companies are filled with people whose whole identity is saying no. Those people will kill your company as you try to pivot to AI, because the shape of your company is going to be really different.

**Milkana:** So you just gave us the playbook for how enterprises should adjust. But what about individuals — people here, or their friends, trying to figure out: is my job at risk? How do I change? A line I keep coming back to: you are either at the beginning of your career right now, or you are at the end of it. You're either getting on this train, or you're missing it. What advice do you have for individuals?

**Steve:** First: you're not any further ahead or behind than anyone else. We're all roughly plus or minus six months from each other. None of this is really that hard to figure out. If somebody makes breakthroughs, you can catch up pretty quick.

It does take about a year to build your AI muscle — because you need to build enough trust with the models that you can actually predict what they're going to do pretty reliably, and you know what mistakes to avoid. The models will screw you any chance they get. People don't realize this right now. We're at the beginning of lots of big services catching on fire, because everyone is doing exactly the wrong thing: leaning too hard, vibe coding straight into production, trusting their LLMs. And it catches fire and burns.

So if you're looking for an opportunity — I predicted a year and a half ago there would be a new profession: the Fixers. The Winston Wolves that come in and fix your screwed-up vibe coded mess. You all are already qualified for that. You're experimenting, you understand how dangerous this stuff is.

My advice to everyone: the world is changing really, really fast. You've got to be super neuroplastic. Nothing like fear and hunger to make you neuroplastic. Find what works for you. You're going to have to hustle — you need to know the old world and you need to know the new world, and you'll need to navigate both of them for a while.

**Ajit:** I want to add a bunch of stuff here. I think one of the benefits of being older is that we've seen previous really nasty crises. I was in the dot-com boom in the Bay Area, at a company called InkToMe. InkToMe was up there with Amazon, eBay, AOL. One day I was at a party and met Dr. Rajiv Motwani — advisor to Larry Page and Sergey Brin — who told me he thought our search engine was terrible. I came back and told my bosses there was this new company called Google. Two years later I was out of a job.

The lesson I learned then: when the world changes this much, nobody in your vicinity actually has a clue what's happening. So when you're cooked, your friends are cooked with you.

This thing Steve talks about — decision making in ambiguity — it's a muscle. If you've just worked in a big company, you don't get to develop it. If you've never had decisions where every decision could tank your company, you haven't built that muscle.

And so when I tell people that everything is different, they say, "I'm going to wait until it stabilizes." This is across the board — early career, late career. There is no stabilization in our foreseeable future. You have to go try things. All your friends telling you it's business as usual may also be cooked.

**Milkana:** You've both alluded to how the next five years will be chaotic. What practical advice do you have for navigating the turbulence ahead?

**Ajit:** First thing: everybody thinks there are only four companies where people have got it made — Nvidia, Anthropic, OpenAI, and maybe one other. Everybody else has no agency. I despise that framing. You've got agency. There are so many SaaS companies that haven't done anything interesting in 20 years. You can figure out an angle based on your domain knowledge and attack them.

The hardest part I'm seeing is that sitting for two or three months with a group of people, working really hard on an angle, requires a level of calm and agency that is hard to maintain amid constant whiplash — new models, geopolitical events, market swings. My best advice is what Ryan and I did: lock ourselves up, don't emerge until you have a working idea, and then pitch people to join you. You literally have to go somewhere and think: what do I have that is worth bringing to the world? And work your ass off.

**Steve:** I would add: team up with other people. You can accomplish more together than by yourself. It's really tempting to lock yourself in your basement with 18 agents and try to take over the world. I know a lot of people doing that. I don't think any of them are going to take over the world.

**Milkana:** How do you distinguish hype from real breakthroughs? There's so much happening — one of the leaders at Anthropic said even she didn't know everything Anthropic was doing. How do you stay on top of it?

**Ajit:** I learned a hack from Steve: he keeps an option portfolio of problems he has in his back pocket and keeps throwing them at AI agents, watching them get better and better over time. The insight I took away is that until you try things yourself, all the hype on X and LinkedIn is almost impossible to understand. So practical advice: just try things yourself. Your intuition about what the models can and can't do is irreplaceable.

The surface of capability is very strange with these systems. At some point they reason like a Feynman-level genius, and then the next question they seem completely lost. You have to figure out the contours on a day-by-day basis. You have to build your own intuition around it. And you have to get more confident in your taste, in your gut feelings, more than you were in the past.

**Steve:** My first instinct is to completely ignore everything until I've heard about it about 50 times. Which has worked out pretty well so far. I think I'm supposed to look at Obsidian next — I think I've heard of that about 48 times.

I think we've reached a point where there's going to be so much software out there that you're not going to be able to pay attention to it all. You'll need search engines, aggregators, eventually a personal agent that knows what you like and finds stuff for you. But the most important thing is that you're trying to build stuff yourself and you've got a feel for how the models are responding today. Because that changes over time, and you've got to develop your own style and taste and vision.

Look, if you want other people to use your stuff, you're all marketers now. Software doesn't just have to be good. It doesn't just have to be elegant. It has to be packaged well. Everything is a show. Everything is an attention economy. But I wouldn't sweat it too much — most of the stuff people are obsessing over will be forgotten in a few months. So: wait until you've heard about it 50 times, wait a few months, and see what's still standing.

**Milkana:** A lot of founders here are wrestling with: how do you build something defensible when code is free? What moats actually exist?

**Steve:** First thing: make sure you know exactly what happens to your product as models get smarter — the bitter lesson. If your product is a bunch of personas, skills, or prompts, the model's going to have all that built in next time around and your company will be out of business. Founders don't seem to know the bitter lesson.

You also have to build something that can't be easily replicated. Anyone can build stuff now — Gastown took me about a month. If you're in SaaS, it's really, really hard to build something that other people will buy because they can build stuff too. And CFOs are tightening their purses. So as a founder, what can you do selling into that hostile market? Build something where they look at it and go: *we could rebuild this ourselves, but that's kind of a big project. Maybe we could just rent it.*

And aim ahead of the models. Build something that doesn't quite work with today's models — something where you're yelling at the model, "Why don't you understand?" — but you know the next iteration will get it. That's what I did with Gastown. I was building with earlier models and by the time 4.5 and 4.6 came around, the thing actually started working. Aiming ahead of the models is underrated.

**Milkana:** How do you think roles change for people building products together? We're seeing designers, PMs, other knowledge workers rely on agents more and more. What does work look like in a couple of years?

**Ajit:** We are in the middle of figuring this out. But I'll be very blunt: world-class thinking has always been scarce. The people who are going to do well are the ones who can think from first principles, work backwards, and don't describe a label to themselves. If you're starting to say "I am a product manager" or "I am a designer," you are going to struggle. You should be able to figure out business, design, product, and tech at the same time.

One of the things I learned from Steve — and from this whole experience — is that we had to go through a cycle of grief and obliterate our old conception of ourselves. Just say: okay, what is it that I can contribute, given the tools we now have? The people who can make that transformation, and who can collaborate with people who are different from them — egolessness and fearlessness — may have a chance.

**Steve:** There's a VC who famously tweeted that there are only four roles in the new knowledge work world. The first: builder — your PM, engineer, agent-builder, get-stuff-done person. The second: SRE, IT security, maintainer type. The third: hot people. There will always be a role for hot people. And the fourth: grownups.

Those are the four roles. To which I say: thank God I'm hot. *(audience laughs)*

**Milkana:** And on the question of human connection — Ajit, I know you've been thinking about this.

**Ajit:** In a very strange way, the desire for human connection has become *more* important in this world, not less. Every meeting with Steve has been a step function in our thinking at SageOx. Real connection, no-bullshit, face-to-face — figuring out what's working for you, not what Twitter says is working — is going to become more and more important because of the whiplash we're all feeling. I am not a social person. I want to be in front of a dark screen. But in this new world, I think these kinds of gatherings and actual face-to-face interaction matter exponentially more. I love this space for that.

### Audience Q&A

**Audience (paraphrased):** You've described how fast this is moving. How do you roll it out responsibly — how do you tell your executives this won't bring things down?

**Steve:** This is the fundamental question. There are companies that are over-adopting — over-confident, under-careful. And there are companies dragging their feet too hard. Striking that balance is incredibly difficult. A concrete example: if you're producing ten times as much code, and your defect rate is roughly constant, you're still shipping ten times as many defects to production. Do you have a plan for that? These are the questions you have to weave into your AI rollout experiments.

I saw one company rolling things out very slowly at the edges of their SDLC — spinning up 100-person innovation teams, keeping the culture side healthy. That's smart. But even they needed a reminder to pump the brakes and ask: are we cramming stuff into production that we shouldn't? I also talked to a bank in Australia that made their engineers five times faster, and the business just couldn't keep up. So they decided to give the business AI too, to help them move faster. The business said: you want us to do five days of work in one day? Not having it. And you can't fire your business. So rolling it out across the whole company slows the brakes a bit — which is, in some perverse way, a feature.

**Ajit:** Galex on our team is going to be doing a talk on what we're doing with BDD — behavior-driven development. We've been burning a lot of tokens on making sure our surface of behavior is well-understood before we ship. We're thinking about things in terms of files and APIs and code, when we should be thinking about the behavior we want to maintain.

And Rupak — he's a researcher from the Max Planck Institute who works on provable systems. His challenge to us is that with these new tools, you can actually start writing provable code from the beginning in ways that weren't practical before.

One thing I'd add for perspective: in 2006, the only companies using EC2 and S3 were startups like SmugMug. Netflix came in 2009. Capital One in 2011. Nobody remembered this was once considered too risky for "serious" companies. No one is going to adopt this all at once. Use your judgment. If you're a Capital One, please don't go crazy. But if you're a startup, the burst of getting something out is worth the risk.

---

**Audience (paraphrased):** I have ADD and agents actually help a lot — I can spawn five or six at once. But the cognitive overhead of managing them is still real. Any tips?

**Steve:** Pre-tool-use hook. That's your friend. Cloud has hooks now — pre-tool-use — and you can put a big block list of things you don't want it to do. Seriously, your ass. It becomes a kind of guardrail layer for the whole swarm.

---

**Audience (paraphrased):** We started this conversation around trust. I've moved to thinking about it more as accountability. At the end of the day, a human head has to roll. Who's accountable when an AI-built system fails?

**Steve:** You actually do need a human at the top of every accountability chain. The CSO role — Chief Information Security Officer — is kind of designed this way. They're sort of designed to get fired every couple of years. That's by design. The accountability structure exists, but it needs to be wired in from the beginning, not bolted on.

**Ajit:** I went through the pain of getting SOC 2 certified for my previous company, and it's a lot. The problem is that when people talk about the past, they act like it was great. It wasn't — it was a bunch of forms fitting together. What you actually need is something that convinces the world that you care, at the level you're advertising. If you're AWS S3, you're advertising a certain level of security. If you're a bank, you're advertising another level. A SOC 2 certification doesn't change the brand obligation.

I think we need more nuanced ways to communicate risk levels — something more granular than what lawyers currently have available to them. And I think we need something like a GitHub for AI-generated code: not just the code, but the model that generated it, the intent, the context. Because these models are going to change constantly. Code that was fine against model 1 might have holes when model 2 changes. The whole world of forensics, security alerting, and auditing needs to be rethought.

---

**Audience (paraphrased):** I'm using agents to code faster, but figuring out *what* to build is still hard. And I find myself doing a lot of throwaway tasks. Am I using this wrong?

**Ajit:** The first part — figuring out what to build — I think of a company searching for product-market fit as a higher-level agent running an observe-orient-decide-act loop across humans and agents. What happens is that the output becomes the bottleneck when the processing gets this good. You end up needing to spend much more time collecting user stories and insights, and doing many more prototypes. That's where the work moves.

On the throwaway tasks: in computer chips there's something called predictive branching, where you execute both sides of a branch before you know which path you'll take. I think we're entering a world where experimentation is so cheap that you should be doing the equivalent. Consistently ask yourself: if I spent ten times more tokens on this idea, could I elevate the experience? You might be surprised. Something that feels like a throwaway might resonate with a segment of your customers.

**Steve:** What you're describing sounds like what I'd call a wedge project — one that keeps weeding out models. Every model drops and still can't do your thing. I have a set of these. For example, there's a React client I'm building for a game I'm working on, and it's still too hard for Opus 4.7. Keep an inventory of these. Every time a new model drops, pull one out and ask: can you do this yet? Usually no, but one day one will. That's the moment you'll viscerally feel how fast the curve is actually moving. Most of us are only looking back six months and forward three months. These wedge projects are anchors on the exponential — they let you feel the motion over years, not weeks.

**Steve:** And there's a level nine that I don't think gets enough attention. Levels one through eight are roughly about how you use agents for development — building stuff interactively. Level nine is deploying 24/7 autonomous agents on your behalf to handle things for you. As soon as you've deployed your first agent somewhere that never sleeps — pulling a queue, doing some ETL, watching for a data condition — you've hit level nine. You don't need to build your own orchestrator to get there. You just need to understand how to use them.

---

**Audience (paraphrased):** I haven't written a single line of code myself in six months — I just direct agents. What happens when Anthropic stops subsidizing Claude Code at the current discount? What do we do when the music stops?

**Steve:** Let's revisit why the discount exists. Claude Code gives you roughly a 20x usage factor at about 95% off the API token cost. The reason is that it produces incredibly valuable training data for their next models. It's one of the main reasons Anthropic is ahead. SpaceX bought Cursor specifically for the data so they could train their models. Should they stop caring about that data? I don't see it shutting off — coding is reasoning and reasoning is problem-solving. They're making general problem-solving models by teaching them to get better and better at coding. That data is going to remain valuable until models can really do everything, at which point we're all in a different conversation.

That said: the open source models lag by about seven months. By summer, we're going to have models as powerful as today's Opus running on local GPUs. The open source path is real. The models only have to be as good as Opus is *today* for the whole game to have changed permanently — and that's already an engineering problem, not a research one. Distillation is also allowing giant models to run on much smaller ones. I'm tempted to think we'll have something Sonnet 3.5-class running on a Mac Mini within the year.

---

*The evening closed with a raffle of signed copies of Steve's book. The question was: "What's one part of building software you think will not change with the adoption of AI?" Some of the best answers from the crowd: "Building software is a people problem, not a technology problem." "Understanding and writing down clearly the problem to be solved." "Figuring out useful problems to solve will still be hard." "The need for humans to understand other humans' intent." And, perhaps most honestly: "Screaming expletives at the computer."*

---

*The recording was made at AI House, Seattle, on May 20, 2026. A signed copy of Steve's book, [Vibe Coding](https://www.oreilly.com/library/view/vibe-coding/), was raffled to lucky attendees. Questions and more: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Milkana Brace</name></author>
<category term="insights" />
</entry>
<entry>
<title>Scribe API Powering SageOx</title>
<link href="blog/scribe-api-powering-sageox.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/scribe-api-powering-sageox</id>
<published>2026-05-22T00:00:00.000Z</published>
<updated>2026-05-22T00:00:00.000Z</updated>
<summary>Ajit Banerjee and Zoom AI&apos;s Zhenbin Xu on how Zoom&apos;s brand-new intelligence APIs — topping Hugging Face&apos;s ASR leaderboards — are now powering SageOx&apos;s real-time speech recognition and speaker identification, and what it took to integrate them in days.</summary>
<content type="html"><![CDATA[
On May 7, Ajit was at an AI community dinner in Seattle and ended up across the table from [Zhenbin Xu](https://www.linkedin.com/in/zhenbinxu/) of Zoom AI. Zhenbin had just shipped a new set of intelligence APIs — real-time ASR and speaker identification — that were topping the Hugging Face ASR leaderboards. Days later, SageOx had it integrated end-to-end alongside WebTransport and Media-over-QUIC (MoQ), enabling a team-standup experience that wouldn't have been possible a month earlier.

This short conversation, recorded in SageOx's offices, is about that integration, the Seattle AI community that made it possible, and why face-to-face collaboration is *more* important now, not less.

A specific kudos to the people who built that room: [AI Tinkerers](https://aitinkerers.org/) — and Joe in particular — and [Tensorwave](https://tensorwave.com/), who hosted *Building the New AI Tool Stack*, the VIP dinner for engineering leaders where Ajit and Zhenbin first sat down. None of what follows happens without that table.

### Transcript

**Ajit:** Thank you, Jonathan, for taking this recording, and I want to welcome Zhenbin to the AI2 incubator space. I want to give a little bit of the story about what we're talking about today.

On May 7th, I was invited to an AI community dinner — this is something Seattle has — that allowed us to sit at a table together. Zhenbin and I didn't know each other before that dinner. He was sitting quite far away from me, and when he came over to talk about what he was working on, he mentioned this new API and new service on Zoom that was very intriguing to me. What it did was top the Hugging Face leaderboards on ASR. Once I heard about it, I didn't even have to talk to him — I came back to the office, and on top of that I learned about a new protocol, [WebTransport](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API), that was supported by Safari as of March 2026, and a protocol called Media-over-QUIC (MoQ), which Zoom is working on along with Meta, Cisco, Akamai, and others in the open-source community.

I was able to fit it all together to have a team-standup experience that's very different from what was possible even a month ago. What I want to highlight is two or three things. One is just how much innovation is happening in the industry — nothing to do with us. This isn't Zoom, this isn't Meta, this isn't AI. The second is that *because* all of these technologies are happening, face-to-face engagements — dinners and actual meetings — are actually becoming more important. So I'm going to pass the baton over to Zhenbin to talk about his side of seeing what he did, and what we're also going to see in the near future.

**Zhenbin:** Yeah, thank you, Ajit, for inviting me over — I tagged along to see all the interesting work you're working on. I'm actually super, super impressed. When you reached out to me, we'd had that dinner, and we'd just released the API. We were proposing it to a few people to see who was interested, but most people hadn't had a chance to adopt it yet. And then a few days later, you reach out and say, "hey, I've already started using the API" — I was super impressed, because you were essentially among the earliest adopters of this API.

The speed you guys are moving at is incredible. What's even more impressive is that you didn't even reach out to ask me, "hey, how do you call this API? How do you get this issue resolved?" — whatever the problem was. You just got it done. I think that's super super impressive.

**Ajit:** I love the service you built — that's why I was jumping up and down when I heard about it. The part I do want to talk about is that people think about startups as being about money, or just the excitement of new things. But I want to talk about how innovation actually happens. You put up a service, you may not have anticipated what I'm going to do with it — but I can just go and *use* it. It's Lego blocks. You're giving me a Lego block, and I'm going to do what I want to do with it. Then I show it to you, and maybe you'll have a different idea after you see what I'm doing.

That ping-pong has to happen between our heads to see what we're doing. And I think that can only happen in places like Seattle, when we get to spend time in front of each other and talk to each other.

**Zhenbin:** Yes, yes, yes. I think there are two things. One: we're in the AI era — and since ChatGPT was released two or three years ago, the entire industry has been excited. Many things are getting better and better. So the industry has been moving — working together, doing all this AI innovation. Zoom is part of that process, doing the transformation. That's one.

The other is being in Seattle — we have this vibrant AI community. You've been in the industry for a long time, and now you're jumping back in, and your company is doing something very innovative.

**Ajit:** What we're trying to do, for reference, is just that we want teams and AI coworkers to collaborate as if humans and agents are the same thing. We're working toward that. But one of the most interesting things is that we believe product development is a team sport, and it's going to continue to be a team sport — it's going to involve teams working together *and* communities working together. You know — you're not part of our team, but you're part of the Seattle community. That's the one thing I want to highlight and take away: it'll continue to always be humans bouncing ideas off each other, alongside AI. I don't think all the narrative about AI replacing humans and human ingenuity is going to happen. It's always going to be humans trying out things with each other, and I don't see that changing ever.

**Zhenbin:** I totally agree. Humans are still making all the critical decisions moving forward — but we now have the AI as a powerful assistant, as a teammate, actually, in the product you're building. You're treating the AI as one of the organization. I think that's super exciting — it aligns well with some things we're building at Zoom. Different in execution, but conceptually we're all embracing this new world where AI is a component of the organization. We're super excited to see how you guys come up with these creative products.

**Ajit:** Let's wrap up this conversation here. One more shout-out to Jonathan, who's part of this ecosystem — you can look over into the video and say hi if you like. Thank you for this. We'll continue now with a little bit more conversation around the technical side.

**Zhenbin:** Yeah, I hope so.

---

*More on the Zoom AI services: [developers.zoom.us/docs/ai-services](https://developers.zoom.us/docs/ai-services/). Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Ajit Banerjee</name></author>
<category term="insights" />
</entry>
<entry>
<title>What Happens to Software Engineering When Generating Code Is Free? (Part 1)</title>
<link href="blog/when-generating-code-is-free-part-1.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/when-generating-code-is-free-part-1</id>
<published>2026-05-22T00:00:00.000Z</published>
<updated>2026-05-22T00:00:00.000Z</updated>
<summary>Dr. Rupak Majumdar — Scientific Director at the Max Planck Institute for Software Systems and SageOx Advisor — on the collapsing cost of code generation, the value of proof, and the trust signals that matter when software is abundant.</summary>
<content type="html"><![CDATA[
Dr. Rupak Majumdar — Scientific Director at the [Max Planck Institute for Software Systems](https://www.mpi-sws.org/) and a SageOx Advisor — reflects on how software engineering is evolving. In this short piece, he explores new research directions opened up by the collapsing cost of code generation: the value of proof, trust signals and transparency, and what it means for the future of software development. These are preliminary thoughts as we work our way toward a better understanding.

### Transcript

**Rupak:** Hi. So I'm Rupak Majumdar. I'm a Scientific Director at the Max Planck Institute for Software Systems, and my research topic is something called automated reasoning, or formal methods. The core idea of formal methods is to make sure that software does what it's supposed to do.

Now in the last six months, I have gotten intrigued by a very new development in the world of software. And that is: some of our basic assumptions about the cost of developing software have changed dramatically. In some sense, today the cost of developing software has gone to almost zero, given all these coding agents that we have. And what I have been thinking about in my research now is what this means for the future of software development. Many of the processes that we have around software engineering practice are based on the assumption that generating software is expensive. So what I'm thinking about these days is: what happens to software development when the cost of software generation goes to zero? Where does the value flow in the overall system?

Of course, if software becomes free, there's going to be a lot of it — and in some sense, a complementary good to software will be some kind of signal that this software is something you should be using. This ties into the research in formal methods that I have been working on, which is proof. If your software came with a proof — a mathematical proof of certainty that it will not do something bad — then that's a fairly good signal that you can trust this software, and you can use it.

And recent work in formal methods also seems to suggest that the cost of proof, along with the cost of generation of software, may very likely go to zero as well. This is an astounding statement for me, because throughout the history of software verification research we have struggled with the lack of scalability of formal verification tools. And now suddenly, with these agents, code generation becomes almost free — and there's some initial evidence emerging that shows the cost of proof also becomes free.

So does that mean we now have verified software and everything is good? Well, not quite. Because when we talk about verified software, we have the software as an artifact, but we also have a mathematical statement — a precise formulation of what it means for the software to be correct. And you can do proof when you have both: the software, and a precise statement of what it means for that software to be correct. This works in a bunch of applications. For example, if I'm developing a storage system, I may want to say, "prove to me that this storage system does not lose my data" — maybe under some assumptions about the environment. But when I'm developing something else — when I'm developing a system that tries to capture intent when teams of developers are working together — I really do not know of a way I can mathematically, precisely state what the specification, what the intent of this software, is.

This just means that proof is one of many signals we can give to show that software is of high quality. There may be other signals that are equally important when we do not have the ability to say precisely, mathematically, what it means for a piece of software to be correct.

This is where there are alternate ways — for example, transparency, or provenance. Imagine that you see a piece of software, and along with the software you also see a transcript of how exactly the software was developed. What was going through the minds of the developers as they were developing the software? For each piece of code, what is the origin of the decision? Now software comes with a transcript of its provenance.

So for each part of the software, you get to see how these decisions were made in order to develop the software. This is not proof in a mathematical sense, but it is also something that gives you a signal of trust in the software — you know exactly why certain decisions were made and how the decisions were embodied into code. So this is actually a very exciting time for software development research, and I think just understanding the various mechanisms that signal trust in new agent-driven software systems will be one of the core directions in software engineering research.

---

*Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Rupak Majumdar</name></author>
<category term="insights" />
</entry>
<entry>
<title>What Happens to Software Engineering When Generating Code Is Free? (Part 2)</title>
<link href="blog/when-generating-code-is-free-part-2.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/when-generating-code-is-free-part-2</id>
<published>2026-05-22T00:00:00.000Z</published>
<updated>2026-05-22T00:00:00.000Z</updated>
<summary>Dr. Rupak Majumdar continues his reflection — this time through the lens of economics. If code generation is the good whose price has dropped, where does the value flow? Substitutes, complements, and the rise of cognitive debt.</summary>
<content type="html"><![CDATA[
In [Part 1](/blog/when-generating-code-is-free-part-1), Rupak introduced the question: what happens to software engineering when the cost of generating code goes to zero? In Part 2, he picks up that thread through the lens of economics — substitutes, complements, and what becomes valuable when code itself is plentiful. Along the way he draws in [Margaret-Anne Storey's](https://www.margaretstorey.com/) recent work on *cognitive debt*: the slow, often invisible divergence in a team's shared understanding of what they're building.

### Transcript

**Rupak:** For a while now, I have been thinking about the future of software engineering practices. This is mainly prompted by the fact that with these coding agents, the cost of development is kind of going to zero. And one of the natural questions then is: where does the value in software development go?

One of the ways to think about it is through the lens of economics. In economics, there are different goods in the marketplace, and some of these goods are substitutes, and some of these goods are complements. Think of substitutes as Coke or Pepsi. And think of complementary goods as, well, gas and cars — or in the software context, commodity hardware and software.

When the price of a good goes up, you would expect that the demand for its substitutes would go up — because, well, Coke is more expensive, I'll switch to Pepsi. On the other hand, if the price of a good goes down, then you would expect that the demand for its complements would go up.

So now let's imagine: we're developing software, and the price of generating the code goes down. The natural question is, where will the value go? In order to understand this, we have to figure out what are the complementary goods to software. If software is plentiful, where should the value be? It has to be something that's rare, that's differentiated, and that's a complement to the code.

If I take my research hat on, one of the things I would say is: correctness of software is such a complementary good. If the cost of software goes down, then you would prefer to get software — or the demand for software — that is also shown to be correct in a certain way would go up.

But of course, this is not the only complementary good. Very recently, Margaret-Anne Storey had a paper where she defined this notion of *cognitive debt*. In software, we say *technical debt* when we're not really doing the right implementations because we feel that we'll fix it sometime in the future. There's also *intent debt*, where we do not really think through exactly what we want to build. And the third kind, *cognitive debt*, is where a team slowly diverges about their understanding of what they're building.

In some sense, cognitive debt is one of those things that is a complementary good to our code. Because in order to build a good product, a good piece of software, you want to ensure that the entire team is aligned to what should be built and how it should be built.

So I think that a very good research area in software engineering today is to understand what kind of tooling and what kind of software development processes we have to introduce in order to focus on the value that you get from the complementary goods to code. And I think tools that essentially bring down our cognitive debt across the team, across the organization, would play a key role.

---

*Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Rupak Majumdar</name></author>
<category term="insights" />
</entry>
<entry>
<title>Trusted Transparency</title>
<link href="blog/trusted-transparency.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/trusted-transparency</id>
<published>2026-05-20T00:00:00.000Z</published>
<updated>2026-05-20T00:00:00.000Z</updated>
<summary>A 10-minute look at our core principle of radical transparency in software development</summary>
<content type="html"><![CDATA[
*This is part of our regular series on new directions in software engineering.*

Many optimization problems can be cast as a particle randomly exploring a state space. You can think of states as particular solutions, and a step corresponds to going to a neighboring solution. A general heuristic for optimization, called “go with the winners”, runs multiple particles in parallel, and every once in a while classifies the particles as “promising” or “not promising.” Each particle that is “not promising” is then moved to a particle that is “promising.”

Quite surprisingly, by coupling independent explorations at right times, “go with the winners” algorithms can outperform multiple independent random explorations, often by an exponential amount\!

The humble particles in go-with-the-winners provide a toy world for software teams. Suppose you are a team trying to find an optimal product-market fit. You and your coworkers simultaneously explore different ideas, you align your goals, and you keep building. Each of you is a particle, your team coordination marks some directions as more promising, and when you align your goals, you move resources to “promising” directions. Each member observes the status of all others, and coordination determines where to go next.

All analogies are wrong, some analogies are useful. The world of randomly moving particles throws away many nuances of software development in the real world but helps us identify a core, and important, coordination principle: *trusted transparency*. Let me walk you through it.

Trusted transparency is the principle that the “state” of each team member is available and queryable by all team members. The state is more than the present work artifacts—code, docs, transcripts—it is also the history of how the team member got to its current cognitive context. Shared state allows quick alignment of resources, from not-promising directions to promising ones.

Transparency is not a new idea: open source projects have done it for decades. Bell Labs ran on hallway transparency, with open-door policies and shared research context as its exploration mechanism. What is new is that AI agents collapse the cost equation that made “record everything” untenable historically: the marginal cost of recording dropped to near zero, and the marginal cost of retrieving and synthesizing insights dropped to near zero as well. (It also helps that we have gotten more comfortable with recorded online meetings\!) The cost of not recording is higher than ever, because each team member generates 10-50x more artifacts per unit of time than before. Simultaneously, an agent can ingest hundreds of hours of context in seconds. In contrast, pre-AI software engineering mechanisms of coordinating context through human-driven summarization (standups, sprints, docs, JIRA tickets) have an increased marginal cost, because human cognitive resources did not scale correspondingly.

**Altered Mechanisms**

A few mechanisms compound when you take the transparency principle seriously.

**The exploration ledger becomes the team's primary artifact.** Not the product — the log of exploration. It's where hypotheses, experiments, partials, failures, and surprises accumulate. Append-only, tagged by area and epistemic status (exploratory / result / decided), queryable on demand. When someone starts a new agent session, the first thing the agent ingests is “what's already been tried in this area.” Learning compounds instead of evaporating.

**Distillations of the ledger become the durable IP.** When agents implement, the intent captured in the exploration ledger outlives the implementation. We care less about the line-by-line code details or current specs. We care more about the decision process: how were the product decisions made? What intent informed the agents? Code becomes regeneratable; distillations of the ledger are the team's accumulated capital.

**Manage coordination while artifact volume explodes.** Amazon is famous for its two-pizza teams: small groups of closely-coordinating developers who maintain coordination. As agents become first-class team members, the pizza is metaphorically sliced among many more team members. This leads to scaling problems: as time for development goes to zero, the cognitive gap in the team goes to infinity. I do not have a quick answer to this scalability problem: we have to build new software development mechanisms that model attention as a resource.

**Trust**

So far, we focused on the transparency part of trusted transparency. Historically, transparency has an unfortunate tendency to become surveillance.

For transparency to compound, trust must be absolute. It is extremely difficult for people to forego their egos, to show their false starts and rambling detours. Ways of ensuring trust and their organizational operationalization are key. Trust can be earned through long-term collaboration, but also included as an explicit organizational mechanism. An example is the “no-blame” approach to correction-of-errors. Another is the charitable interpretation doctrine: when interpreting an idea, focus on the ways it may work rather than the ways it won’t. Remember that in exploratory mode, novelty is what you optimize. An interesting failure is a more valuable indicator for novelty than a mundane success.

Trust is necessary. If the ledger becomes a weapon—for penalizing “bad paths”, for settling old scores—people withdraw rather than expose themselves. Transparency becomes performative: people stop sharing half-baked ideas, maintain private scratch spaces and public sessions. The context becomes hidden.

Trust is necessary but not sufficient: we still have to ensure the flow of independent context. It is easy for context to converge prematurely, as desire for group coherence dominates independent exploration. More on this in a future post.

**Bottom Line**

The principle:

**default to public, structured, queryable, distillable artifacts, paired with operational trust commitments.**

Transparency makes context visible and shareable across the team. Trust commitments separate transparency from surveillance—they have to be enforced, not just stated.

The bet I'd make: the small exploratory teams that find product-market fit in the next few years will look unusually transparent and unusually organized. This is by no means obvious. Full transparency and ledger-as-source-of-truth is a large cognitive shift from the way we work in teams. There is a core technical challenge is to distill the ledger to move knowledge across the team. But the rewards that compound from the trusted transparency principle are likely to outweigh the uncomfortable downsides of rethinking software development practice.

]]></content>
<author><name>Rupak Majumdar</name></author>
<category term="insights" />
</entry>
<entry>
<title>GeekWire: Seattle&apos;s SageOx Lands $15M to Help Humans and AI Agents Work in Lockstep</title>
<link href="blog/geekwire-sageox-15m-funding.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/geekwire-sageox-15m-funding</id>
<published>2026-05-06T00:00:00.000Z</published>
<updated>2026-05-06T00:00:00.000Z</updated>
<summary>GeekWire covers SageOx&apos;s $15M seed round and our mission to build shared context infrastructure for AI-native teams.</summary>
<content type="html"><![CDATA[
<a href="https://www.geekwire.com" target="_blank" rel="noopener noreferrer">GeekWire</a>'s coverage of our $15M seed round explores how SageOx is building the missing infrastructure layer for teams working alongside AI agents.

From the article:

> As organizations increasingly operate through fleets of AI agents, a new reality is emerging: humans and AI are now coworkers, but they are not yet a team.

The piece highlights our approach to capturing context where it naturally occurs — across conversations, coding sessions, and existing tools — and turning it into structured knowledge that flows into every agent interaction.

**<a href="https://www.geekwire.com/2026/seattles-sageox-lands-15m-to-help-humans-and-ai-agents-work-in-lockstep/" target="_blank" rel="noopener noreferrer">Read the full article on GeekWire →</a>**
]]></content>
<author><name>The SageOx Team</name></author>
<category term="announcements" />
</entry>
<entry>
<title>Humans and AI Agents Are Now Coworkers — But Not Yet a Team. SageOx Raises $15M to Fix That.</title>
<link href="blog/sageox-raises-15m-seed-round.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/sageox-raises-15m-seed-round</id>
<published>2026-05-06T00:00:00.000Z</published>
<updated>2026-05-06T00:00:00.000Z</updated>
<summary>A shared context layer that captures decisions, intent, and history to keep humans and AI agents aligned.</summary>
<content type="html"><![CDATA[
**SEATTLE, Wash., May 6, 2026** — SageOx, a startup building shared context infrastructure for AI-native teams, today announced a $15 million seed round led by Canaan, with participation from A.Capital, Pioneer Square Labs, and Founders' Co-op.

As organizations increasingly operate through fleets of AI agents, a new reality is emerging: humans and AI are now coworkers, but they are not yet a team.

Today's AI agents operate in isolated sessions, with no shared memory of prior decisions, architectural intent, or team discussions. In practice, that means every task starts from scratch, forcing teams to constantly restate context and correct drift. The result is misalignment that compounds across the system, amplified at machine speed.

SageOx is building the missing context infrastructure to solve this problem. The platform captures context where it naturally occurs, across conversations, chat, coding sessions, and existing tools, and turns it into structured knowledge that flows into every new agent interaction. In practice, this means agents can pick up work with full awareness of prior decisions, generate outputs that reflect team conventions and architectural intent, and stay aligned as projects evolve — without constant human intervention. The result is a continuously aligned system in which decisions, intent, and history are seamlessly shared across humans and AI agents.

> "As an in-person team, a lot of our best decisions happen in conversation. Before SageOx, our agents weren't part of that; they felt remote. We had to constantly recap decisions, and things would get lost. Now SageOx keeps them in the loop automatically. Conversations turn into output in minutes. It's fundamentally changed how we build — less translation, more collaboration."
>
> — **Marius Ciocirlan**, CEO at Mark OS

> "We're at the beginning of a fundamental shift in how knowledge work gets done, where teams increasingly operate as a combination of humans and AI agents. Every major shift like this creates a new systems layer, and in this case, that layer is context. SageOx is building that foundation, and we believe it has the potential to become core infrastructure for this new era of AI-native work."
>
> — **Kumar Sreekanti**, Venture Partner at Canaan

> "As teams begin operating at multiples of their traditional speed, in some cases 20x to 40x faster, their existing processes break down, and the ability to share decisions, intent, and history across humans and agents becomes critical infrastructure."
>
> — **Ajit Banerjee**, Founder and CEO of SageOx

---

SageOx is already working with early design partners and has adopted an "open work" model, giving users visibility into how its own team builds alongside AI agents — a live demonstration of its core belief that knowledge should be continuously captured and shared.

The company was founded by **Ajit Banerjee** (CEO), **Ryan Snodgrass** (CTO), and **Milkana Brace** (CPO), a team with deep experience building and scaling foundational systems. Banerjee was an original member of the AWS EC2/EBS team, helped build core infrastructure at Apple and Facebook, and founded XetHub (acquired by Hugging Face), which now powers over 100 petabytes of data. Snodgrass was one of Amazon's first engineers and helped lead its transition from a monolithic architecture to microservices, later scaling cloud systems that support tens of millions of Kindle devices and earning more than 35 patents. Brace is a repeat founder and former EVP of Product at Remitly, where she helped guide the company through rapid growth following the acquisition of her startup, Jargon. The team is rounded out by **Galex Yen**, a veteran builder, leader, and entrepreneur, with advisors including author **Steve Yegge** and researcher **Dr. Rupak Majumdar**.

SageOx will use the new funding to continue developing its product and make a small number of key hires while remaining intentionally lean and relying heavily on agentic teammates. The company sees itself as building a foundational layer for AI-native work, much like cloud infrastructure defined the last generation of software.
]]></content>
<author><name>The SageOx Team</name></author>
<category term="announcements" />
</entry>
<entry>
<title>VentureBeat: AI Agents Are Missing All the Discussions Your Team Is Having — SageOx Has an Answer</title>
<link href="blog/venturebeat-agentic-context-infrastructure.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/venturebeat-agentic-context-infrastructure</id>
<published>2026-05-06T00:00:00.000Z</published>
<updated>2026-05-06T00:00:00.000Z</updated>
<summary>VentureBeat explores how SageOx is solving the context gap between AI agents and the human conversations that shape team decisions.</summary>
<content type="html"><![CDATA[
<a href="https://venturebeat.com" target="_blank" rel="noopener noreferrer">VentureBeat</a> dives into one of the core problems we're solving at SageOx: AI agents today are completely disconnected from the conversations where real decisions get made.

The article explores our concept of "agentic context infrastructure" — the missing layer that captures discussions, decisions, and intent as they happen, then makes that knowledge available to every agent interaction.

> Today's AI agents operate in isolated sessions, with no shared memory of prior decisions, architectural intent, or team discussions. In practice, that means every task starts from scratch.

When your team debates an architectural approach over coffee, when a product decision gets made in a quick sync, when someone explains *why* the code works this way — that context disappears the moment the conversation ends. Your AI agents never knew it happened.

We're building the infrastructure to change that.

**<a href="https://venturebeat.com/technology/ai-agents-are-missing-all-the-discussions-your-team-is-having-sageox-has-an-answer-agentic-context-infrastructure" target="_blank" rel="noopener noreferrer">Read the full article on VentureBeat →</a>**
]]></content>
<author><name>The SageOx Team</name></author>
<category term="announcements" />
</entry>
<entry>
<title>How SageOx Got into Firmware</title>
<link href="blog/how-sageox-got-into-firmware.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-sageox-got-into-firmware</id>
<published>2026-04-20T00:00:00.000Z</published>
<updated>2026-04-20T00:00:00.000Z</updated>
<summary>The unexpected journey from AI coding assistants to embedded systems. How a side project led SageOx into the world of firmware development and hardware integration.</summary>
<content type="html"><![CDATA[
We recorded this video three months to the day after deciding to build the context layer for AI-native teams. In it, we talk about how, in less than two weeks, Ryan and Ajit built the firmware for a device we now expect to be central to our product—despite having no recent hardware experience on the team. It's been incredibly energizing to see how much creativity and innovation are unlocked when building becomes this fast and accessible.

**Milkana:** So today's April 20th, which is a very special date as you pointed out because it's exactly three months.

**Ryan:** Three months.

**Milkana:** Three months after we started working on this idea with this company and it's absolutely astounding to me given where we were three months ago because just so many things have come together. It's like beyond exciting. But the reason why we wanted to chat here was because last week Ryan talked about the potential for what this product can become and how it completely changes how humans and agents interact in a very seamless way and in a way that makes human interactions a lot richer and a lot more human in a way. And just the way you laid out that vision and what was possible was absolutely amazing and I was really moved to tears.

It's interesting to reflect back on how did we get here because how we got here was actually a very compressed timeline and it started a few weeks ago when we were thinking we need an always on recording device we need something and then we were all kind of running in different directions and hadn't really done any research and then Galex you joined and then you took this idea and you ran with it and that was really kind of like the first thing that got this process started.

**Galex:** Yeah, it's kind of fuzzy now even though it was only a couple of weeks ago. But I think we were at a lunch and someone mentioned this idea of like a room OS and Ajit was really excited about this idea about a room OS and we started kind of talking about oh what if we had a device hanging from the ceiling that was constantly recording and so we didn't have to remember to always hit record on the app or on the phone or on the computer. And I thought well that that's actually that seems like that seems plausible. Why why is that not plausible?

And I vaguely remember recently somebody posted on Hacker News, oh, someone's building something for Home Assistant. And so I thought, there's got to be something. And I went and looked around and searched, like not even 30 minutes of searching. We found a device. And it turned out that device is available on Amazon. So I ordered one on Amazon. And I actually ordered a few more from Waveshare and AliExpress.

And then the first one showed up, I think like a couple days later, maybe three. Oh, no, about a week later. About a week later. So, it's like a Thursday, dropped it into the office, and then we didn't do anything with it. We were all really busy Thursday. And then Friday night, we were all about to leave. Ajit's like, "Okay, I'm going to play with this this weekend."

And then I get a text message later that evening. And Ryan's like, "Uh, I took the device, FYI. Was that cool?"

**Ryan:** Well, to be fair, I actually took the device. I was like, because I was working late that I was playing with it and I bricked the device. I'm like, "Uh oh, the device is totally bricked. If I don't take it home and fix it, he's not going to be able to work on this." So, I took it home like while I'm fixing all these other things, I'm kind of experimenting with getting this thing up and running.

**Milkana:** And what exactly were you hoping to do? Because the device arrived as is. So, what were you like at that point? What were you hoping to achieve?

**Ryan:** At that point, I just wanted to boot up and like maybe be able to hit record and get something like, oh yeah, this microphone's on. That was really the hope because there's a lot of work just to get a firmware that's custom for a device up and running.

**Ajit:** So now I show up on the weekend thinking that there's going to be a device in the office and there isn't any device unlike WTF. And so the interesting thing here is that both Ryan and I have touched firmware way back in our life. Ryan's worked in the Kindle team in the 2006 2007 era. I did some kind of initial embedded device work in the late '90s. But then I'm like texting Ryan. I'm like yo I need this device.

And so I end up going to his place and we actually have a recording on the SageOx public repository on that Sunday where we meet up and Ryan being Ryan's done this thing where you see this device. It used to be just this, you know, black circular device, but by the time I get my hands on it, it's got our Oxy mascot on it and it is so cute. The moment you see it, you're like, "Oh, there is an element of toy likeness to it."

And actually, you should talk a little bit about how you went to that part. I thought your initial session where you kind of dropped all the PDFs and the things was a very interesting unlock because you know from the Kindle time you would have expected something like this to take like 6 months or a year and in two days you had this thing functioning and I think this is something which is very interesting that you got us to.

**Ryan:** Yeah I think one of the things is a lot of stuff wasn't very well documented there was like documentation different places my starting point was like okay let me do a quick search and find some working maybe a demo in GitHub some stuff from Waveshare some documentation on the thing. I mean all these things I just dumped it into Claude and said hey here's some reference things and like let's start by kind of extracting what we can and figure out how we can build any firmware on this device that might get up in our own. So that was kind of the unlock to Claude to like okay how can they play around with this device.

**Ajit:** So the two of us kept ping ponging back and forth. That week was actually the week after that was a we were busy with something else. One of the things that I remember on the next weekend was that I actually got that murmur from you which is going to be one of my fond memories of the development process where as it turned out this device had two form factors a V1 and a V2 and we had not figured it out because it just powers up and has a V1 or a V2 and it just goes away and we didn't know that and at one point on some Sunday you had figured it out and I remember sitting here and I felt like you know like like God has whispered into my ear saying that hey there's a V1 and what had happened was that you had done a you had figured it out and the ox murmur had fed into my Claude saying that I need to go mono versus stereo because the V1 was messing up the audio. That was such a key unlock.

But anyway, I think it's now like 8 days since Galex has shown up with this device and then I'm going to pass it back to you where we've got this thing now working to the point that we have a meeting with our dear friend Steve.

**Ryan:** I think the interesting thing is like we start on Friday, we handed it back and forth. Monday we actually had working reporting like you know as proof of concept that this actually could work uploading into SageOx. And so yes, it took a couple more days to kind of like work out all the kinks and to learn V1 versus V2 hardware and they worked differently.

**Ajit:** Wait, wait a second. We also did that video and we kind of put it up on the LinkedIn that also went viral and we started getting some really good feedback from people even at this junky state where you clearly saw that this was buggy but it was still getting something here, right?

**Ryan:** Yeah. So I think then it was what we were 10 days in we met Steve Yegge you know at our great origins of this company at my mom's apartment and as usual Steve's coming he's talking and talking and we plump down the device you know which here's one of these devices we plop it down the table for him you know and we started explaining what was this thing here and unlike Steve he was kind of befuddled for a little bit and like didn't know what to say when he saw it like and we talked about what it was doing and it was a good 10 minutes before he kind of had gathered all his thoughts and like could see just where this was taking us on some of his grand visions that he's kind of shared with us in the past. So I thought that was really for me a special moment.

**Ajit:** And you pointed out like Steve not having words which does not happen but the other gesture which I remember was that Steve made something like give it to me and what he said was that man there's just so many people who are coming up to me with giving all kinds of like these agent take flows and all of that you guys are thinking about team coordination in a different way and I want to play with this I want to play with this for my team which we are you know geographically remote etc etc etc and you know one of the things that I really take is when people are so — everybody is like oversold in tech right everybody's like yeah this is going to change your life but when you see somebody actually lean forward and want to kind of grab that thing from your hands that's a very very interesting signal.

**Milkana:** So I think it's very exciting to talk about and then what right so this device got to a working state we put it in front of a few people the reaction was pretty similar in that they all wanted it and they could you could see their ideas starting to just keep generating about like oh and I can do this and I can do that and we've had people, you know, send us suggestions inbound, which has been very exciting. And then that kind of led to an event that happened just late last week. The event that did bring tears to my eyes when you pieced together all of these things that could be possible because of this device and because of you know your own breakthroughs and some of the conversations that had been happening in the room and it just kept snowballing and snowballing and snowballing and that led to you buying a TV over the weekend and bringing it to the office this morning and to me that was incredible.

And you know we talked about like well how did we get here? Was it like this vision and it was a vision but it was not a vision that you started with and we worked backwards. It was a vision that kind of evolved because of a very different way of working. Can you reflect on that a bit more?

**Ryan:** I mean I think the ability to kind of experiment and learn quickly something that is so fundamentally different than a few years ago right like you write a stack and you implement and like okay months later you get to that point you're like okay now we have something working. What's possible? What next can we do?

Well, if that what's possible moment happens, you know, every day because you utilize all these AI tooling and techniques and ways of work, you really get that ability to every day think, well, okay, what if I can do this or what if I can do this? You can dream a lot bigger. You know, part of this came from listening to what was being said as we met customers like Mark OS. I remember the meeting with them. It's like ah like light bulbs were coming off as we're having discussions and like why isn't that possible? Like why can't we do that? You know, we have the ability to experiment and prototype in interesting ways and see if something is possible today that may not have been possible 6 months ago.

**Ajit** I want to talk a little bit about that. You know, when you're kind of describing this idea, you said that we have stumbled upon something which is way bigger than we started. And this is like 12 days after this initial kind of thing. And so there is like a lot of kind of why not or why not try this? And so this started off with just this idea of like yeah it must be around this this device where you don't have to take your cell phone or open up your laptop. This must be around. And this kind of this idea that much more of the solution space is explorable and actionable is something which I don't think most people get.

On one side you can say that we kind of stumbled into luck. There's a lot of hard work that happened here to make this luck possible but more than that I think the most interesting thing that we need to capture for everybody who's watching this is that what you can do in 10-12 days is just remarkably bigger than what you could do in 2025 or any time before that in human history. And I think it starts with just saying why not let's try to see what we can do and if other people have built a form factor who knows what else we can build.

And I think the other part about that whole lucky or the stumbling part is that because we're also in this world where we're showing it to people we're getting very good reaction your daughter talks about how she wants to take it to the school you know my friend is talking about how he wants to use it for his brother who has cerebral palsy so other people we can show it and they can open doors for us about like hey why don't you do this and because we're going through that idea cycle so fast we can give it to other people and play around with this and then we get new ideas and then then we cycle faster and faster.

**Galex:** Yeah, this point that you just made that when you actually see the product like being demoed, it's different than when someone is painting an abstract concept and you know putting together a spec. There's something different when you actually see the actual thing working because you play with it a little bit and then your mind goes to new places and when you're asking yourself what can I like what are other things that could actually happen? What could I do? And you start imagining these other possibilities.

And I think what's interesting is when we met MarkOS for example we showed them the puck they were already like really — they were they loved playing with it. But then we said, well, what imagine if you did this and you could see light up in their eyes. The ideas like light up. They could because they could actually see the device. They could see what was happening, right? New ideas, I think, become easier to visualize. Right? And I think that's what led to this cascade of like these crazy ideas that that Ryan had, right? Because he could visualize all of these things after playing with it for a few days.

**Ryan:** I think you're really on something there. This, you know, when it's an abstract, you can't really iterate that quickly in your mind even like is it possible? In the old days, you know, what's abstract is a spec. Like, yeah, you've written it down, but you don't know if it even works. You don't have any of this yet, but when you like touch it, you're like, well, the next step is not too far away.

**Milkana:** And here in this conversation, we talked a lot about speed, but one thing you call out often is that it's not just the speed that is dramatically different. It's what's possible. You know, you hadn't touched firmware in 20 years, and over a weekend, you figured out how to make this device work, right?

**Ajit:** Two weekends.

**Milkana:** But doing a bunch of other things. My point is like it's an unlock on the types of things that we can tackle not just at the speed with which we iterate.

**Ajit:** Yeah, I think if anybody's watching the one takeaway that I would love it if anybody takes away is that you got to be fearless about what is possible because all of us now have this AI tools in our pockets. There's just so many more things that one can try which in the past you wouldn't even have dared to try and when you start daring to try I think this whole business of stumbling upon luck happens and it's almost hard for us to capture — I mean we actually got the recording of this feeling of the room's electricity but I just want to recap when does it happen that somebody actually has tears in their eyes when they hear a vision and that happens because of this combination of like fearlessness experiment lots of hard work right there. Lots of dead ends, don't get me wrong. There's lots of trial and error, but to be able to get that feeling is something really weird. It was special.

**Milkana** It was the only time in my career it has happened. But I do want to call out one thing, which is we talked about this device and how we got here over the last 12 days or however long it's been. But if you just step back and look at the last three months since we started to work on this idea, I mean, the same pattern has been true throughout those three months as well. You know, I mean, we build product and infrastructure and a device and the ideas that are ahead of us now and are getting clearer and clearer and frankly bigger and bigger and that's just absolutely incredible.

**Ajit:** Yeah. People didn't believe us when we said that we'd written whatever many maybe like one plus million lines of code in two months. And I think the fact that this is not only doable, but it's now going to be mundane. More and more teams are going to be figuring out how to do this is something that I'm super excited about to see what human potential and ingenuity is unlocked by this. We are unlocking it in our world with like making knowledge work be very multimodal very fluid in the state of flow but this is like something which has got implications across the world of human kind of innovation and technology and I cannot wait to see what else is out there.

**Milkana:** Awesome.

---

*We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>SageOx Team</name></author>
<category term="insights" />
</entry>
<entry>
<title>Lessons Learned from Implementing an Open Claw for Slack Integration</title>
<link href="blog/lessons-learned-open-claw-slack-integration.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/lessons-learned-open-claw-slack-integration</id>
<published>2026-04-10T00:00:00.000Z</published>
<updated>2026-04-10T00:00:00.000Z</updated>
<summary>Galex Yen shares insights on building a skill for Open Claw — from navigating Claw Hub security scans to optimizing token usage for hands-off automation.</summary>
<content type="html"><![CDATA[
## Building for Open Claw

Galex Yen shares insights on building a skill for Open Claw — from navigating Claw Hub security scans to optimizing token usage for hands-off automation.

### Transcript

**Milkana:** Galex, can you talk about some of the work you've done recently with Open Claw and an implementation for a feature you're working on — what you've learned and problems you've run into?

**Galex:** Yeah. So we're working on this feature that we wanted to integrate with Slack, and we realized that it's very natural that we use Open Claw to actually do that integration — because Open Claw naturally has all of these different channels that integrate agentic workflows. So we started to set out figuring out how to actually set up a Claw, how to get our software on there, and how to then build a skill that would utilize our feature in Claw. That was probably the biggest learning for us — how to build that skill.

**Milkana:** So you said you had to write a Claw skill, and you used Claude to write the skills, right? Did you consider other options — like ChatGPT, for example — for writing the Claw skill? And what about writing the Claw skill was different from all the many skills you've written for Claude?

**Galex:** Yeah, I actually started using Claude chat to help investigate how to even go about building out the skill. It was different because it's a different environment from Claude itself. I didn't understand how to define things like prerequisites. How do you make sure that the software you need is running on your Claw? How do you make sure to set it up appropriately?

I went back and forth with Claude, and it helped brainstorm what are the right ways to go about doing this. When we got further into actually developing it, Claude was a really great resource because I could constantly ask it: "How do other people who are building skills solve these problems? How do they make sure the appropriate tools or credentials are available?"

One of the tricks was to ask it, "In April 2026, what is the right way to do this? What are people doing?" And we came up with very specific recommendations — use these declarations in the skill, which are very Claw-specific. Use these declarations to say you need these credentials. That back and forth was very productive.

What was interesting though — later on when I went to Claw Hub, that's the place where you publish your skills. I noticed they do a really great service: they do a security scan of the published skills, because it's kind of the wild west right now. There are all these skills out there, and they do a really good job scanning through to see if this looks like an abusive skill or a malicious skill trying to exfiltrate information.

Once I realized that was the case, we needed to figure out how to prepare for these scans. Again, Claude was really helpful. I asked it how to figure out if I'm going to get flagged from the scan. In this particular case, I was able to point Claude to the Claw Hub code and say, "Take a look — tell me what they're doing." It came up with a way to actually codify the scans. It helped scan our own skills. It found a bunch of things it flagged and said, "Hey, these will get flagged" — and it helped me correct all of those errors.

**Milkana:** That's a really good hack. But I'm curious — do you think the skill ended up being more secure or of better quality, or did it just prepare better to pass the exam? How effective is the Claw Hub at scanning?

**Galex:** That's a really good question. I think yes — it actually is better. They look for various things that look malicious. For example, if it looks like you're trying to install your tool in an opaque way that could actually be installing some malware, they flag those patterns.

In our case, because we wanted to make sure the ox CLI was being installed on the Open Claw instance, we had to think about the safe way to show that we're installing something legit — not potentially malicious and opaque about it.

The other thing is that they also look at the instructions in the actual skill itself. If it looks like you're doing something malicious — like trying to exfiltrate information — they'll flag it. In our case, I wanted to have an option where you could get the latest version of the ox CLI, so you could compile some code. I wanted to make sure that if that's in the skill, we do it in a way that's transparent and doesn't look malicious, even though we're actually executing code.

**Milkana:** So far I've heard a couple of takeaways. One is that you used Claude to help you define the Claw skill. The other is that you asked Claude to give you best practices or instructions as of April 2026 — because of course everything changes so fast. And then also you asked Claude to help you prepare for the scans of Claw Hub and ensure that the skill would present well.

**Galex:** Yeah. As a matter of fact, not only did it help me prepare for the scan on a surface level, but we ended up adding another skill within our own codebase that is an ongoing linter. So it actually codified some of the rules that it read in Claw Hub and turned that into a skill for constantly checking the skill that we're building.

**Milkana:** And I'm sure the rules in Claw Hub are also constantly changing themselves, so that skill needs to be refreshed. If you were to write your next Claw skill now, how would you go about it differently?

**Galex:** That's a good question. I think it was good to ask "what are the best practices from April 2026 going forward." I would ask Claude to look at various other repos. One of the things I would do differently is to ask Claude to search for what are the existing repos related to the space, update its instructions on how to go about reviewing and building out a new skill — kind of refining its own learning by constantly reviewing what are the current available repos out there.

**Milkana:** And what are the skills that are performing well?

**Galex:** Exactly. Take a look at Claw Hub itself. Look at the skills that are popular. Understand how they're structured. Learning by example — I think that would be one additional change.

**Milkana:** Curious if there are any things that stand out for you between writing a Claw skill and a Claude skill. Were there any patterns worth flagging?

**Galex:** Yeah, definitely. A Claude skill — you tend to assume there's quite a bit of tooling already, and you're working within the confines of a developer toolkit. You can tell the skill "here are some things to check for" and handle errors if those things aren't there. If you don't have the GitHub CLI, you can just tell the user "you should install the GitHub CLI."

With Open Claw — because it's more hands-off, that's the MO: you want more automation, the human is not necessarily in the loop every time the skill is running — you do have to think about these error conditions. You have to think about the preconditions your skill is built around. You have to think more about the robustness of the skill. I think that's some learnings and patterns that as a group we'll all begin to learn.

**Milkana:** Curious if token usage was a consideration as you were writing the Claw skill.

**Galex:** Yeah, glad you brought that up. It definitely was and is still a consideration. We were very intentional about creating a different API key for Open Claw so that we could monitor the skill and cap the usage on a daily basis.

There were a couple of things we learned — like to actually tell the skill when it should output things and when it should read the output, because all of those use tokens. If part of the skill doesn't require outputting to the Slack channel, it doesn't make sense for it to consume all those tokens. So it was important to think about the structure of the skill and how many tokens the commands would generate. There is some optimization. I'm still watching the token usage to make sure we're efficient. Definitely a concern.

**Milkana:** Anything else at this point?

**Galex:** I'm excited to show everybody eventually the features we've been building that we're using Claw for.

**Milkana:** Hopefully very soon — in the upcoming days.

**Galex:** Yeah.

**Milkana:** Awesome. Thank you so much, Galex!

---

*Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>The SageOx Team</name></author>
<category term="insights" />
</entry>
<entry>
<title>How We Work: Source Code Management in Agentic Engineering</title>
<link href="blog/how-we-work-source-code-management.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-we-work-source-code-management</id>
<published>2026-04-08T00:00:00.000Z</published>
<updated>2026-04-08T00:00:00.000Z</updated>
<summary>Part 5 of our How We Work series. Ryan Snodgrass on how branch management, commit strategies, and repo structure need to evolve when AI agents are writing most of the code.</summary>
<content type="html"><![CDATA[
*This is Part 5 of our [How We Work](/blog?tag=how-we-work) series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.*

## Source Code Management in Agentic Engineering

### Transcript

**Milkana:** Can you talk about any strategies or thoughts you have around branch management, or even repos, that have evolved in this agentic world when things move at such incredible speed and when you have a lot of parallel work happening?

**Ryan:** Yeah, I mean certainly our philosophy has changed. Ajit and I used to get in a little bit of argument sometimes about what's the right size for a PR, how many commits. We — he wanted to see a lot less, because initially we're coming from that BC, "before Claude" era, where you do things like git bisect and git log and you can make sense of the codebase and the stream of work that's coming in, because it's at human pace.

But I think we both realized at some point that just no longer makes sense. And in fact, it's actually bad for the agents when you have a PR that's like 10,000 lines with changes all over the codebase that are completely unrelated, just to make it look like a nice clean commit history. The reason is, if you want agents to go back and look at previous commits, it's very hard for them to reason about what the heck was this change for, because it's touching a little bit of everything.

So smaller commits, much higher volume, very focused and targeted is better. There's a balance there. I mean, sometimes I still have way too big commits just because you're in the flow and you're working in one work tree and you're just like, "I don't want to spin up another work tree just for this one thing. I'm right here, just fix it while I'm doing this."

**Milkana:** And have your thoughts around the repo mapping and structure changed in this new world?

**Ryan:** Yeah, I think it's evolving right now. I mean, we really have loved having a monorepo in the sense that the coding agent can make sense of everything, and that has been really important. Although we have a separate design system repo and a separate repo for the CLI.

I think what we've observed is that at least with coding agents today, they often get lost when the repo is really large. So yes, you can build quickly, but once you get to a larger size repo — I don't know, we have like 750,000 lines of code right now — it might be better to break that down into smaller chunks. More well-defined, almost like when we went from monolithic services to microservices.

I think there's probably something to be said for breaking down repos into more micro-repos. Especially as agents are dealing more with all the dependency management, PRs, and dealing with the fact of having to port things across repos. That would have been annoying to humans too, to manage all this. But if you're not having to manage it as a human, agents might be very good at that. So I think that's something we'll probably explore at some point.

Right now we're still in a monorepo. But I think that's got to be something we revisit. And again, all these things that we've used as software engineers over the decades and learned — almost all of them you can say, "Okay, throw that out. Let's start from first principles. How should it be?" And then obviously you'll bring some of those techniques back that just make sense. But it's really a fresh opportunity to face these with new perspectives on how things should work.

---

*We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Ryan Snodgrass</name></author>
<category term="insights" />
</entry>
<entry>
<title>How We Work: From Ideation to Execution</title>
<link href="assets/how-we-work-ideation-to-execution.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-we-work-ideation-to-execution</id>
<published>2026-04-07T00:00:00.000Z</published>
<updated>2026-04-07T00:00:00.000Z</updated>
<summary>A 10-minute look at how we operate as an AI-native team — from ideation to execution — with a real-world example from Pier 70 in Seattle.</summary>
<content type="html"><![CDATA[
*This is part of our [How We Work](/blog?tag=how-we-work) series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.*

As a brand-new company, we have a unique advantage: we get to rethink everything from the ground up—not just our product, but how we work.

In a world that's changing rapidly, AI allows us to build at speeds that were previously unimaginable. But it's not just about going faster. We're redesigning our workflows entirely—how ideas are generated, how decisions are made, and how execution happens.

The way our team builds is fundamentally different from traditional approaches. We're developing new methodologies and tools that make our process not only 40x faster, but also more creative and genuinely fun.

In this 10-minute video, you'll see a real-world example from Pier 70 in Seattle (yes, that reference). It walks through how we operate—from ideation to execution—and gives a glimpse into our world.

If you are an AI-native team and want to adopt similar tools and practices, we'd love to connect.

---

*Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>The SageOx Team</name></author>
<category term="insights" />
</entry>
<entry>
<title>How We Work: Working on UX Projects</title>
<link href="assets/how-we-work-ux-projects.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-we-work-ux-projects</id>
<published>2026-04-05T00:00:00.000Z</published>
<updated>2026-04-05T00:00:00.000Z</updated>
<summary>Part 4 of our How We Work series. Ryan Snodgrass on using multiple AI models for design work — and why ChatGPT generates better design prompts than Claude for visual tasks.</summary>
<content type="html"><![CDATA[
*This is Part 4 of our [How We Work](/blog?tag=how-we-work) series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.*

## Working on UX Projects

### Transcript

**Ryan:** There's still a lot of manual stuff I do that obviously we need better tooling around. A good example is in design — when we're working on a website, so often we're taking screen snapshots and pasting them into ChatGPT, because it's a much better designer than Claude ever is, even though we've tuned with experts in design systems and all these things. ChatGPT just has a much better design sense for whatever reason.

**Milkana:** That's been my experience. Yeah, way better.

**Ryan:** And so you take that, you say, "Here's what I'm struggling with and I want it to be more Apple-like," or whatever your inspiration is, "and can you give me a Claude Code prompt out of that?" That will refine it. And you take that prompt and put it over into Claude. So there should be better tools, but that is very effective.

**Milkana:** You've shared this tip with me in the past and I've used it and it's just so amazing. I love it so much.

**Ryan:** And so it really works. What I'm hoping too is that some of our new features for SageOx around Loom videos, screen recordings, all these things where you can do walkthroughs and be talking about the product — that some of that manual snapshotting and moving between models and everything becomes much more automated.

**Milkana:** Because for instance, we will take out of the video the 20 frames that really matter in the discussion, and now you'll have screenshots for all those and Claude can work on those.

**Ryan:** And hopefully over time we can figure out how to get ChatGPT also to weigh in on those same things, because again, it just does a little bit better job of that.

---

*We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Ryan Snodgrass</name></author>
<category term="insights" />
</entry>
<entry>
<title>How We Work: Improving Prompting by Learning from Teammates</title>
<link href="assets/how-we-work-learning-from-teammates.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-we-work-learning-from-teammates</id>
<published>2026-04-03T00:00:00.000Z</published>
<updated>2026-04-03T00:00:00.000Z</updated>
<summary>Part 3 of our How We Work series. Ryan Snodgrass on why seeing how your teammates prompt and reason with AI coworkers is one of the biggest learning accelerators.</summary>
<content type="html"><![CDATA[
*This is Part 3 of our [How We Work](/blog?tag=how-we-work) series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.*

## Improving Prompting by Learning from Teammates

### Transcript

**Milkana:** Can you talk about where else or how else you use this technique of finishing the work and then asking Claude to learn from how you got there and whether there's a better way to have gotten there? Where else do you apply this approach?

**Ryan:** I certainly apply it to the team stuff we're doing with SageOx. Like, looking at what Ajit has been doing lately — how would Ajit solve this problem? And so I use that as a self-reinforcing thing. It's like, the team has learned how to do certain things in a certain way — why am I not embracing that, taking that, applying that? So that's one thing. The other is I'll have—

**Milkana:** But can I interrupt you? Sorry, but isn't that — you have to use SageOx because SageOx is also capturing what Ajit is doing and feeding that into the context?

**Ryan:** Correct.

**Milkana:** Just without SageOx, just in Claude, you wouldn't be able to do that, right?

**Ryan:** No, some of it I'd be able to do. What you would get out of that is you'd get from the Git history what was implemented.

**Milkana:** Okay. You'd not get the why.

**Ryan:** But not the prompts, the intent, the reasoning — which is really kind of what differentiates maybe Ajit's approach from person XYZ's approach. There's only so much you can get from the output. Right, you can see, "Oh, this is a great job," and "Oh, that was interesting how this was structured." But you don't know how it got to that point and what were the important questions to ask.

I found that really useful, especially in bootstrapping my own learning.

**Milkana:** I think that's where you get a lot of value out of seeing how other people operate.

**Ryan:** Yeah. It's just like me sharing here — same sort of thing. You'll go look at my sessions and think, "Oh, that was such a genius prompt that you used to get to the root of that problem. I wouldn't have thought of it that way." And so again, there's so much in just how you express to the agents how to think about and reason about what you're trying to ask. Seeing how other people do it is a big jump forward.

---

*We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Ryan Snodgrass</name></author>
<category term="insights" />
</entry>
<entry>
<title>How We Work: Working with Multiple Agents in Parallel</title>
<link href="assets/how-we-work-parallel-agents.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-we-work-parallel-agents</id>
<published>2026-04-01T00:00:00.000Z</published>
<updated>2026-04-01T00:00:00.000Z</updated>
<summary>Part 2 of our How We Work series. Ryan Snodgrass on going from 50 agents to fewer, more focused ones — and why that&apos;s actually a sign of progress.</summary>
<content type="html"><![CDATA[
*This is Part 2 of our [How We Work](/blog?tag=how-we-work) series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.*

## Working with Multiple Agents in Parallel

### Transcript

**Milkana:** I know that earlier on, you had up to 50 agents working for you in parallel, which is insane. I cannot even imagine how that works. And you mentioned that more recently, you have been working with fewer agents. Curious to know why — what was different then, what is different now? Is that more a function of the type of work you're doing and the maturity of the product, or is that more a function of things you've learned that make you more efficient?

**Ryan:** A combination of things. I think early on, even when Opus 4.5 came out, it was much more effective if you had lots of agents spun up — even if they were stomping on each other. Because at the end of the day, it's really about outcome. How quickly can you get to your outcome? As a human, it's okay if these agents rewrite things multiple times. It does not matter if they're having merge conflicts. It's not like the same irritation that you would get with engineers on your team if you were giving them the same thing. And it's really fine to throw stuff out.

So I think at that point in time, it was just way easier to unleash a whole bunch of agents, even if they're stomping on each other, with a set of epics and Beads and everything, and then come back and check on it in an hour and see where it was at.

I think now, with Conductor and with just improvements in Claude itself, you don't need as many agents to get the same outcome in the same amount of time. And plus, you don't have the stomping effect as well. So I think that's an important thing.

And then, again, if you can have a lot of these going in parallel, even if some of it's not quite as fast, you don't have to spin up quite as many agents — and that's okay.

I also feel like Claude has gotten much better at understanding dependencies if you're using Beads — like what should be in what order. So it almost makes it a little harder to spin up as many agents, which is actually a good thing. They would only spin up like six or ten or fifteen, whatever it was. Or the team would only spin up so many. Because it's much more thoughtful about the ordering, so that these merge conflicts and stomping on each other doesn't happen.

---

*We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Ryan Snodgrass</name></author>
<category term="insights" />
</entry>
<entry>
<title>How We Work: Beads, Conductor, Expert Agents, and Skills</title>
<link href="assets/how-we-work-ryan-snodgrass.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/how-we-work-ryan-snodgrass</id>
<published>2026-03-29T00:00:00.000Z</published>
<updated>2026-03-29T00:00:00.000Z</updated>
<summary>Part 1 of our How We Work series. CTO Ryan Snodgrass talks about the tools and workflows that have been the biggest unlocks in agentic engineering — from Beads for task tracking to creating expert agents by combining multiple AI models.</summary>
<content type="html"><![CDATA[
*This is Part 1 of our [How We Work](/blog?tag=how-we-work) series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.*

In a world that's constantly changing, how we work also needs to rapidly evolve. Our CTO, Ryan Snodgrass, talks about having to sharpen his axe frequently, constantly on the lookout for better ways of getting the job done. Consider his thoughts below relevant as of late March 2026.

## Beads, Conductor, Expert Agents, and Skills

### Transcript

**Milkana:** Across projects and also within a project when you have multiple agents maybe tackling different parts of the project — what tools do you use or what flows have you set up for yourself around that?

**Ryan:** To me the absolute biggest unlock you can have with any of these agents is use Steve's Beads, to be honest. When it came out I was a very early adopter. I did a lot of contributions to Beads early on because it was such an instrumental change from the way that Claude and other coding agents used to create a markdown plan.

The problem with the markdown plans is that when you use them for implementing, it has to have the whole plan in memory and then it's marking off the things it's completed. Well, that's not very efficient for its context. There's a huge amount of state. So if you can instead, up front, take that plan and break it down to a series of epics and then all the tasks with lots of details on what needs to be implemented — now you have the plan and you have this kind of breakdown of all the work.

And why that becomes really powerful is when you start thinking about how do you keep a huge swarm of agents fed with work. Well, now you can spin up a number — a swarm, like five agents with Conductor — and say, "You tackle this one epic," which is usually pretty isolated from the others. And you spin up another tab and say, "You do this epic and these tasks." You can do it with many of those and they can all work in parallel and keep track of just the specific tasks they have to work on.

Again, the agents work the best when they have enough context but not too much. So if they're spinning up and they're just taking a single item out of Beads and working on that, then they're very focused and they can not get confused as much. Because when you start doing huge things across the codebase, Claude will just spin and spin sometimes and go in circles. But the more fine-grained the task, it seems to do a better job — and then you merge them back later.

**Milkana:** Can you talk more about Conductor?

**Ryan:** As you look at the history of the unlocks — when Opus 4.5 dropped, it was a big thing. Then sub-agents dropping allowed you to have these experts that could tackle specific portions of the problem. But so much you had to manage yourself. You had to manage your tabs. I'd have like 10 tabs across my terminal, each one being different Claude instances, and then remembering, "Oh, tab number four is this and tab number one's this." So the first thing I was doing was color coding them and knowing which ones were operating on production data, which ones were the CLI, which one was the back end. You built your own processes around that.

But what Conductor did — I think it was really smart — was it made some of the things that you naturally want to do, like work trees, super easy. Everything is in a work tree. It names the branches for you automatically. On the tabs on the side, instead of having like number one, two, three, it tells you what it is, what repo it's working in. There's a lot of dashboard things, kind of like on a Tesla — you can see if you're doing a PR, it pops up when there's conflicts or merge issues or when it's ready to be pushed, without you having to go check multiple pages. So you can just quickly move around in Conductor to look at your work.

To me it was a big unlock just to have the work tree support, which you could do manually before. It just ended up being such a hassle managing all these work trees myself that I kind of abandoned it and for a while was just letting Claude stomp on each other and implementing features in the same branch. But Conductor really helped make that smoother and easier because I just want things to get out of my way.

**Milkana:** So you talked about three big unlocks — Opus 4.5, Beads, and Conductor. Have you had any other unlocks, whether it's tooling or...?

**Ryan:** Yeah, I think the biggest thing — and I think people still don't use it enough — is expert agents and sub-agents in Claude. The way I create those is if I can start getting into a situation I'm not as familiar with, or even if I am, I need an expert on maybe side projects, things like microprocessor programming. So I need to create an expert in that. I need an expert in release management for open source software. I need an expert in test harness strategies.

Well, you can create these agents. You can go find repositories out there. What I found really effective was actually using ChatGPT, not Claude, to create these. So you go to ChatGPT and say, "Hey, I need an expert in these things, this skill set. I want it to be utilizing the best practices and techniques as of March 2026. And I want this to be a Claude Code prompt that I can just drop into Claude Code to create this."

**Milkana:** Do you feed it any further context, saying like, "I want this style" or "I want these guidelines"?

**Ryan:** Yeah, I think on a case-by-case basis, if you have insights in explicitly what you want, that dials in the experts even more. Like in the microprocessor case for the hobby thing, it was this specific circuit board — that's what matters. And you can imagine the same thing in whatever project you're working on. Like, we're using GitLab, so let's have a GitLab expert, not just a Git expert.

And then you take that, you paste it into Claude, and then you have Claude rewrite it. You say, "Rewrite it with the most effective way that Claude will use it as of March 2026." So now you've gotten the insights from ChatGPT, which thinks a little bit differently than Claude, and you have then Claude editing that and merging it to itself. You end up getting something better than either of them could have produced. I think that's an important concept — kind of getting the best of multiple models ends up with something that neither of them could have come up with.

**Milkana:** How frequently do you update these experts?

**Ryan:** That's a really interesting question. I tend not to update them very often. But I'll say recently, because at SageOx we have these agents and we share them within the team, I was thinking, "Oh, we really need these customized to each of our repositories or to our team."

So I kind of went through this process and I realized it's just like hiring. It's like, "Hey, I want to hire a test harness expert, but it should be an expert that is based on what our codebase is and what we're trying to build." So I basically told Claude, "I want to hire this agent from out of this other team and I want it customized specifically for this repository." And so it went through and looked at how we structured our architecture and it rewrote it and customized it for that. Which I thought was really interesting — because just like when you're hiring, you might say, "I just want a security engineer." Well, no — I want a security engineer that's really knowledgeable about the specifics of the product we're building. It's very similar in the agent world as it is in the physical world.

**Milkana:** Can you talk about how and whether you use skills?

**Ryan:** I do use skills. I probably should do a better job with using skills. I think that's one of the things I realized — if you don't go back and sharpen your axe every two weeks right now, at least, you're getting behind.

I do use skills. I have a lot of my own custom ones built. I've also tried various ones that are out there, which I think are interesting. If you usually embrace their whole process, you can get some amazing things out of the box. I think Gary Tan's launch recently of GStack was a good example of that — you can really embrace that. But you can come up with your own too, based on your workflow.

So one of the things I did recently was I felt like my skills were getting a little out of date, and I was often doing stuff manually. So I said, "Go look at all my Claude sessions for the last month across all my projects. What are the really key things that I should take away from what I'm doing, and new skills I should create based on that?" Because clearly I've unlocked or figured some things out, but I haven't really taken the time to sharpen my axe and sit back and think, "Oh, I really need this specific skill." And it did a fantastic job of building a new toolkit for myself.

That's a compounding thing. Over time, you're going to keep doing it — "Hey, based on the things I did last couple weeks, update my skills." And that could be because you've brought in GStack or other things and you're starting to use those in a certain way. So your other skills might need to be tweaked.

---

*We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: [feedback@sageox.ai](mailto:feedback@sageox.ai).*
]]></content>
<author><name>Ryan Snodgrass</name></author>
<category term="insights" />
</entry>
<entry>
<title>Your CLI Has a New Super User</title>
<link href="assets/your-cli-has-a-new-super-user.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/your-cli-has-a-new-super-user</id>
<published>2026-03-13T00:00:00.000Z</published>
<updated>2026-03-13T00:00:00.000Z</updated>
<summary>A new category of CLI user has emerged: coding agents operating in loops, generating plausible commands without reading documentation, and exploring interfaces as black boxes. How friction data from agent interactions is reshaping CLI design — and why the teams that instrument this feedback loop will build tools that improve themselves.</summary>
<content type="html"><![CDATA[
Something unexpected is transforming developer tools. For decades, CLIs were built assuming human users — people reading help text, skimming documentation, making predictable mistakes. That assumption no longer holds true.

A new category of user has emerged: coding agents operating in loops, generating plausible commands without reading documentation, hallucinating flags, and exploring interfaces aggressively as black boxes rather than cautiously like humans.

## The Core Insight: Desire Paths

Steve Yegge's concept of "Agent UX" captures this phenomenon perfectly. By observing what agents attempt to do with tools, developers can identify desired features and implement them. This mirrors the "desire paths" phenomenon on university campuses — dirt trails that appear where people actually want to walk, not where planners intended.

Agents carve similar paths through CLIs. They might try `ox agent-list` instead of `ox agent list`, assume `--format=json` exists, or invent commands like `deploy --env staging`. These aren't irrational hallucinations — they reflect reasonable assumptions about how good software should behave.

## Friction as Product Signal

Rather than treating agent errors as failures, forward-thinking teams can view them as valuable data. This observation led to the development of **[FrictionAX](https://github.com/sageox/frictionax)**, an open-source Go library that intercepts failed commands and treats errors as learning opportunities.

FrictionAX operates through three mechanisms:

1. **Command Correction**: Using a three-tier suggestion system (learned corrections, token-level fixes, Levenshtein distance matching)
2. **Structured Response**: For agents, it emits JSON metadata explaining the canonical command format
3. **Telemetry Collection**: Capturing friction events across user bases to identify patterns

The library distinguishes between human and agent users, providing "did you mean?" suggestions to humans while offering structured JSON guidance to agents for immediate, in-context learning.

## The Friction Dashboard: Product Development Reimagined

At SageOx, aggregate friction data revealed unexpected feature opportunities. When agents repeatedly attempted a command like `ox agent OxFxV0 query "Team discussion..."`, the team didn't dismiss it as hallucination — they built it as a feature. Team context search shipped within seven days; codebase search followed three days later.

![SageOx's internal FrictionAX dashboard shows agent friction patterns across ox CLI commands.](/blog/frictionax-dashboard.png)

This represents a fundamental shift: "Intelligence is abundant and getting cheaper. Judgment is scarce and getting more valuable." Friction dashboards amplify human judgment by surfacing significant patterns from thousands of agent interactions.

## AgentX: Agent-Aware Infrastructure

Complementing FrictionAX, **[AgentX](https://github.com/sageox/agentx)** enables CLI tools to recognize which agent is calling (Claude Code, Cursor, Windsurf, etc.), what capabilities it possesses, and how to format output it can parse. A single `agentx.Init()` call propagates agent information across entire tool pipelines through an `AGENT_ENV` variable.

## Design Philosophy: Accept Everything, Expose Nothing

A counterintuitive principle emerges: accept all hallucinated commands but never expose them in `--help`. If `code query` works but remains hidden in documentation, agents learn the canonical approach without polluting the interface. Hidden Cobra commands silently redirect while keeping help text clean.

This design principle — generous in functionality, opinionated in teaching — represents a philosophy applicable across agent-aware tooling.

## The Missing Category: Agent Experience Platforms

Just as PostHog instrumented web product development, a new category of "Agent Experience (AX) tooling" is emerging. These platforms answer critical questions: Which commands do agents try that don't exist? Where do multi-step workflows break? How do different agents behave differently?

The team building this category for the agentic era will achieve what PostHog accomplished for web analytics: become billion-dollar companies by making invisible phenomena visible and actionable.

---

Traditional developer tools assume human users reading sequentially, learning through exploration, remembering imperfectly. Agents consume context windows, learn through correction, and hallucinate plausible interfaces. As agents become primary CLI users faster than most realize, the teams that instrument agent feedback loops will build tools that improve themselves — while others install metaphorical "Keep Off the Grass" signs.

**Resources**: [FrictionAX on GitHub](https://github.com/sageox/frictionax) | [AgentX on GitHub](https://github.com/sageox/agentx) | [SageOx](https://sageox.ai)
]]></content>
<author><name>Ryan Snodgrass</name></author>
<category term="engineering" />
</entry>
<entry>
<title>The Hive is Buzzing</title>
<link href="assets/the-hive-is-buzzing.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/the-hive-is-buzzing</id>
<published>2026-03-10T00:00:00.000Z</published>
<updated>2026-03-10T00:00:00.000Z</updated>
<summary>How a hallucinated CLI command became two shipping features in ten days. The story of Ox CLI v0.3 and v0.4 — and what it reveals about building tools for coding agents.</summary>
<content type="html"><![CDATA[
*Prefer video? [Watch the v0.4 discussion](https://www.youtube.com/watch?v=ODMZyEU3Bz8) with Ryan, and Yucheng and Ajit.*

On February 27th, I was reviewing agent friction logs when I saw this:

```
ox agent OxFxV0 query "Team discussion between Reza and Vikas about restaurant integration"
```

The `ox agent query` command did not exist in v0.2. The agent hallucinated it. But what struck me wasn't the hallucination — it was the *intent*. Claude wanted to search the team's discussion history. It assumed it could. It was right to assume it could. We just hadn't built it yet.

Seven days later, team context search shipped in v0.3. Three days after that, codebase search joined it in v0.4.

## Desire Paths

The idea traces back to a conversation on February 18th between Ryan, Steve Yegge, and me. Steve had been writing about what he calls the [Desire Paths approach to agent UX](https://steve-yegge.medium.com/the-future-of-coding-agents-e9451a84207c):

> *I have been curating Gas Town the same way I did Beads, using the Desire Paths approach to agent UX. You tell the agent what you want, watch closely what they try, and then implement the thing they tried. Make it real. Over and over. Until your tool works just the way agents believe it should work.*

Ryan internalized this before we shipped Ox CLI v0.1. He built what we call the **agent friction dashboard** — a client-side system that logs every command an agent attempts, whether it exists or not. Hallucinated subcommands, misspelled flags, invented syntax — all captured.

We plan to break the friction tooling out as standalone libraries for others to embrace these Agent UX ideas — a form of PostHog for agent CLIs. But right now, our focus is taming the startup chaos in the hivemind. The classic information retrieval progression: collect, organize, index, distill. The friction dashboard is the *collect* step. Everything else follows.

![SageOx friction dashboard showing recent friction events](/blog/friction-dashboard.png)

It captures the mental model that agents carry about how a tool *should* work. When Claude tries `ox agent query`, that's a signal. When Codex tries the same thing with different syntax, the signal gets stronger.

## From Hallucination to v0.3

That hallucinated `query` command told us agents wanted to search the Team Context and the Ledger — the team's discussion history, decisions, and session records.

By March 6th, Ox CLI v0.3 shipped with team context search. The approach was classic information retrieval: BM25 for keyword precision plus vector search for semantic recall. Not because it was fashionable — because we ran the numbers.

I had coding agents work through a dozen retrieval strategies: managed RAG services, multiple embedding models, knowledge graphs, vector-only search. The agents executed the evaluations. But the *choice* — BM25 plus vector hybrid — was mine. Small embeddings fail on proper nouns. Managed RAG services lose precision on our corpus size. That's judgment, not intelligence.

## Champagne and a Source Graph

On March 4th, Ryan and I met Dr. Yucheng Low at Tomo in White Center. Yakira got us champagne. The conversation wandered to a thought I'd been sitting on: it would be useful to have a source graph — a structured index of the codebase that agents could query alongside the team context.

Yucheng's response: "Let's just try it."

By Thursday night he had a working implementation. Claude wrote all the code. About $20 in extra API usage.

Yucheng didn't just prompt an agent and accept whatever came out. He has decades of experience in graph databases and distributed systems. He guided Claude through sensible architectural choices from the start — choices that would have taken weeks of wrong turns without that background. The agent was fast. Yucheng's judgment made it accurate.

I asked Dr. Rupak Majumdar — programming languages researcher, based in Germany — to review Yucheng's work and build a Go implementation. Rupak's `codedb-go` landed by March 7th. Same pattern: Claude wrote the code, Rupak's expertise in code analysis steered the decisions. I pulled both implementations into the Ox CLI on Sunday, and Ryan cut the v0.4 release on March 9th.

Dinner conversation to shipping feature. Five days. No PRD. No Linear ticket. No Notion doc. This code went from human-human conversations stored in the Team Context and human-agent sessions captured in the Ledger — straight to production. The traditional artifacts didn't exist because the system that replaces them *is the product we're building*.

## Tiki-Taka

It's impossible to give individual credit when the team operates like this. The idea didn't belong to anyone. It sprang from the common brain pool — the hivemind — and moved through people the way a ball moves through Barcelona's 2011 midfield. Xavi to Iniesta to Messi. No one holds it long. Everyone touches it. The play is the thing.

You can think of SageOx as a self-evolving entity. The friction dashboard surfaces what agents want. Humans with judgment pick the next move. Agents build it. The hivemind records what happened and why. The next agent session starts with all of that context loaded. Closed loop. None of us can afford to care about credit at this pace of iteration. The only winner is the customer, who gets to see a blitz of features that no planning process could have produced.

## Intelligence is Cheap. Judgment is Everything.

Steve's desire paths. Ryan's agent friction dashboard. Yucheng's source graph. Rupak's Go rewrite. My retrieval engine. In each case, the agent produced the code. In each case, a human with domain expertise chose the path.

Intelligence — the ability to generate plausible code — is abundant and getting cheaper by the month. Judgment — knowing which of the ten plausible approaches is actually right — is scarce and getting more valuable.

The friction dashboard isn't an intelligent system. It's a judgment amplifier. It surfaces the signals that matter and lets humans with taste decide what to build next.

## The End of the Giant Repo

Steve made an observation during an earlier conversation that stuck with me. He talked about how monorepos at big companies — the ones with 10 million, 20 million lines — became comprehensible only to the humans who'd spent years navigating them. That institutional knowledge was the moat.

Agents are about to hit the same wall. Context windows are finite. A repo that's too large for an agent to hold in its head is a repo where the agent makes bad decisions. The same scaling problem that created the need for senior engineers at big companies is going to create the need for *smaller, more numerous repos* at fast-moving teams.

We think code is going to fragment. Not into chaos — into well-indexed, queryable modules sized for agent comprehension. The tooling to navigate across those modules — searching team context, querying code structure, understanding the *why* behind the *what* — becomes the critical infrastructure.

That's what Ox CLI v0.4 starts to deliver. A query layer that spans the team's collective memory and the codebase, running on a developer's laptop. No managed service. No cluster. An M-series Mac and the accumulated judgment of the team, encoded in the hivemind.

---

*Want to see how we build? Signed-in SageOx users get a live view of the Ox CLI's development. [feedback@sageox.ai](mailto:feedback@sageox.ai)*
]]></content>
<author><name>Ajit Banerjee</name></author>
<category term="insights" />
</entry>
<entry>
<title>The 40x Team</title>
<link href="assets/the-40x-team.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/the-40x-team</id>
<published>2026-03-03T00:00:00.000Z</published>
<updated>2026-03-03T00:00:00.000Z</updated>
<summary>A step-by-step guide for technical leaders on how to adopt AI-native workflows and reach 40x engineering velocity. We built SageOx in three person-months — the same milestone that took seven person-years at our previous company. Here&apos;s the playbook: from running your first AI bootcamp to fielding a team of AI coworkers.</summary>
<content type="html"><![CDATA[
Ryan, Milkana, and I built SageOx in a matter of weeks. My previous company, XetHub, used a broadly similar technical stack and reached a comparable product milestone in seven person-years of engineering effort. In 2026, operating in the Claude Opus 4.5 era with an AI-native workflow, we reached the same stage in three person-months.

That's a 40x speedup. It's why we call ourselves the 40x team — and we believe this is only the beginning.

Since the public launch of SageOx on February 19th, I've fielded a wave of questions from technical leaders who want to bring these ideas to their own teams. After enough 1:1 calls covering the same ground, I decided to write it down — a step-by-step path from where most teams are today to where we believe they need to be.

## Month 1: Get to 10x Without SageOx

**Week 1: Get Claude-pilled yourself**

November 2025 was an [inflection point](https://simonwillison.net/2026/Jan/4/inflection/). You need to arrive at a deeply felt conviction: the only thing that matters in the first half of 2026 is the pace of experimentation on new customer features and new business models.

Catch up on the new [coding workflows](https://x.com/karpathy/status/2004607146781278521). Get current with the latest models and tools. Start making changes in your team's production repositories — yourself.

**Week 2: Run a week-long bootcamp with your team**

Ask the people on your team who want to reach 40x to volunteer for a bootcamp. Bring everyone to one place. On the first day, make it clear: no regular work responsibilities. Their only job is to build the hardest thing they're willing to imagine — a new language, a new database, a new version control system.

Encourage them to dream big. Software teams in 2026 who have embraced this speedup have:

- Built a CDN from scratch in Rust
- [Rebuilt Next.js](https://blog.cloudflare.com/vinext/) in one week for a 4x speedup
- Reimagined git for the world of agents and implemented [cxdb](https://github.com/strongdm/cxdb)

On day 1, you will be nudging them to think bigger. Remind them: unlimited token budget on the latest models. The only constraint is their own creativity.

By day 3, every one of your colleagues will be personally experiencing the dopamine rush and the sleepless nights that [Steve Yegge talks about](https://steve-yegge.medium.com/the-future-of-coding-agents-e9451a84207c). By the end of the week, you will find the number of repositories exploding as your team bursts with ideas to try in production.

**Weeks 3 & 4: Post-bootcamp restructuring**

If your bootcamp succeeds, your team will want to keep working at this speed. The changes that follow are predictable:

**Micro co-located teams.** Three people, max. They sit together — physically. Communication overhead scales quadratically with team size.

**Spend big on the tokens.** Budget half an engineer's salary per team for agent usage — roughly $30K. They won't spend anything close to this. But you want to signal with hard dollars that experimentation at this velocity is what you actually want.

**Autonomy is the default.** Get comfortable with the idea that code will reach production which may not have been read by any human. One mantra from a leader who gets this: *if you're not causing outages occasionally, you're not moving fast enough.* Experimentation is everything right now.

## Month 2: Embrace SageOx for the 40x Speedup

As the first ideas from the 10x phase approach production, more people need to be brought up to speed — PMs, designers, infra engineers. This is the stage where most teams collapse back to 1x. Long meetings. Alignment overhead. The velocity dies.

This is the friction Ryan and I felt firsthand. We built SageOx so teams don't fall into this trap. The only way to sustain velocity past the first month is when all the context — the *why* behind the code — is stored in a form that both humans and agents can access.

**Record everything.** If it's not recorded, it didn't happen. Every conversation, every decision, every whiteboard sketch, every pairing session — captured and searchable. This isn't surveillance. It's leverage. When your human and AI coworkers can query a full history of why a decision was made, what was tried before, and what the customer actually said on that call, they become dramatically more useful. Institutional knowledge stops living in people's heads and starts living in a system that never forgets.

**Work in the open.** Every team member can see every other team member's work in progress at all times. The psychological barrier is real. Most people don't want others seeing their rough drafts. But rough drafts shared in real time are how 40x teams operate.

**No decision is sacred.** Within SageOx, we often use the phrase **BC — Before Claude** — to mark prehistoric choices unlikely to survive the AI-native era. Run a weekly ritual: *what are we doing because it's what we've always done?* Tools that made sense before coding agents existed might be dead weight. Processes designed for teams of twenty might be strangling a team of four. Architectural tradeoffs made when compute cost X might be wrong now that it costs X/10.

## Month 3: Rinse and Repeat

The next model will drop and everything changes again. But now you'll be thinking about projects sorted by complexity. Some of the work your team attempted in Month 1 and Month 2 will suddenly be feasible — re-attack them with the latest model and see what happens.
]]></content>
<author><name>Ajit Banerjee</name></author>
<category term="insights" />
</entry>
<entry>
<title>Introducing SageOx</title>
<link href="blog/introducing-sageox.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/introducing-sageox</id>
<published>2026-02-19T00:00:00.000Z</published>
<updated>2026-02-19T00:00:00.000Z</updated>
<summary>The hivemind for agentic engineering. Agentic context infrastructure for AI-native teams.</summary>
<content type="html"><![CDATA[
<IntroducingSageoxContent />

]]></content>
<author><name>The SageOx Team</name></author>
<category term="announcements" />
</entry>
<entry>
<title>How We See the World</title>
<link href="blog/hello-world.html" rel="alternate" type="text/html" />
<id>https://sageox.ai/blog/hello-world</id>
<published>2026-02-03T00:00:00.000Z</published>
<updated>2026-02-03T00:00:00.000Z</updated>
<summary>We founded SageOx in Seattle in January 2026. We exist to empower the most ambitious builders of the AI era.</summary>
<content type="html"><![CDATA[
> We founded **SageOx** in Seattle in January 2026. We exist to empower the most ambitious builders of the AI era.

An unprecedented wave of innovation is here. This is a moment to reimagine what's possible. To question defaults. To discard inherited constraints. To build.

For those who adapt, it's energizing. For those who don't, it's destabilizing. We choose to lean into both realities.

The shifts below define the opportunities we see and the company we're becoming. In a world moving this fast, we'll revisit these beliefs often.

## Destruction is Part of Creation

Coding agents reached human proficiency in late 2025. Software development changed forever. Products are no longer hand-written. Code is generated—increasingly, it ships with no human intervention. One person can oversee dozens of agents building in parallel.

The ecosystem that defined the last era is being dismantled. Processes. Tooling. Roles. Skills. All of it. And it will be rebuilt.

This reset isn't a phase. AI today is the least powerful it will ever be. Destruction and reinvention are the rhythm. Everything is provisional.

## A Builder's Moment

We're entering one of the great value-creation windows in history.

Billion-dollar companies will be built—and rebuilt—by teams small enough to fit around a table, in timelines that once seemed impossible. Scale, headcount, and inertia are now liabilities.

Advantage comes from clarity. From speed. From leverage. From teams who know how to turn AI into force, not just assistance.

We're here to help unlock it.

## Survival Belongs to the Adaptive

We've spent decades at the frontier of software. This moment humbled us.

The mental models, skills, and professional identities that got us here don't survive this era. To build now, they had to burn.

The pace is uncomfortable. Disorienting. Sometimes painful. But on the other side is something electric—the ability to turn ideas into reality at a speed that was unimaginable before.

Survival belongs to those who reinvent themselves—unlearning quickly, growing constantly, pushing through discomfort. Individually. And as teams.

---

*That's the company we're building at SageOx.*

*And those are the builders we're building for—and with.*

---

**— Ajit, Ryan, Milkana**

[@sageox](https://github.com/sageox) · [@port8080](https://github.com/port8080) · [@rsnodgrass](https://github.com/rsnodgrass) · [@milkana-stack](https://github.com/milkana-stack)
]]></content>
<author><name>The SageOx Team</name></author>
<category term="announcements" />
</entry>
</feed>