# The Rise of Agentic Workflows and Local AI Models

**Podcast:** Dev Interrupted
**Published:** 2026-04-17

## Transcript

So, Andrew, are you as excited as I am about this news that Google is going to start punishing websites that hijack your back button?
I mean, for me, it's a little too late.
It's like I'm not going to those websites anymore.
My agents are.
So did it did it take my agents complaining for them to finally do something about like the back button not working on on like bad websites?
Oh, yeah.
So you're saying it's Google's token costs were getting too high because their agents back button was getting hijacked.
So they now they're going to take action on it.
Or maybe I didn't take the thesis that far.
But now that you've said it, that's very compelling.
These agents were getting caught in these loops.
But I do love them.
I do love the movement that Google is, you know, continuing to fight spam.
It's not during a time when like bad practices on the web are at an all time high in terms of spam and vibe coded websites that don't act like you maybe expect.
And so any kind of pulse check from Google of like, hey, we still care about spam on the Internet is or, you know, bad.
Internet website practices is a win in my book.
What do you think about it?
Yeah.
I mean, it makes me just wonder, like, how many other things out there do Google see that are like, wow, it's our agents are having a really hard time consuming websites that do this.
So we should go punish those websites.
Like, they're probably like the only company in the space that actually has the authority and power to do that.
Right.
Like, they truly are interesting.
They have a unique moat in terms of, you know, kind of owning how people were consuming the web in the first place.
Yeah.
Yeah.
Well, awesome.
Welcome to the Friday deploy from Linear B and Dev Interrupted.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
And this week, we're covering Google's offline AI breakthrough agent swarms for data teams.
Obsidian isn't AI memory, or is it when we talk about Carpath Carpathian, his self-writing wiki?
And lastly, we'll close out with the AI brain fry epidemic.
Andrew, let's just start right at the top with this new Google Gemma news.
What do we have?
What do we have here?
Yes.
So continuing the story we've been covering about small language models, open source models, alternatives to the foundation models like Anthropic and Claude.
This is an article about highlighting Gemma 4's ability to run natively on the iPhone, which is something that we have called out here on the show before when we first talked about it after its unveiling about two weeks ago.
Yeah.
It's a great reminder about all the different variants of this model and how they're optimized for mobile devices, devices on the edge, devices in infrastructure.
And if we're going to talk about the Internet as bad as mine.
And this represents like a major shift towards Internet and places where Internet or rather AI in places where Internet connectivity is spotty.
There's like a real danger in the world of a lot of populations getting frankly left behind in the AI revolution.
And personally, I see Gemma as a really great step towards making AI more accessible to the rest of the world.
Yeah, a lot of a lot of people and use cases, I think.
And I think it's it's interesting to know that I think it feels like Google's really trying to make things more accessible to the rest of the world.
Yeah, a lot of a lot of people and use cases, I think.
to position this as something for developers and power users to treat as like a foundation for for future capabilities rather than like a feature that they're rolling out to users which totally makes sense to me i mean the average ai user isn't going to know like which tasks are appropriate to hand off to a local model nor would they even know how to do that in the first place often uh you know and like you said we've been covering a lot of these stories of how local models are becoming more efficient higher quality easier to delegate sub-agent tasks to and i really do think this this type of stuff is going to open up a lot of efficiency gains but it's also going to do a lot of open up a lot of new use cases where you need like either offline ai completely or some sort of a edge ai capability where it's just too expensive to go back to a central service for you know api services versus just trying to do it locally so yeah you know a lot of companies are competing in this space more and more it's really exciting to see google being a part of it as well particularly because you know as we covered in our opening they have a lot of they have a lot of power in their incumbency that lets them you know get push this stuff out in a way that other companies may not be able to do so yeah i think this is we'll definitely be following this a lot more because i think local models are increasingly going to become like the story of the rest of this year maybe so i completely agree um it's an opportunity for us to be able to do this for everyone to get involved and to reduce their costs like we even covered the shopify story i think like two weeks ago yeah how they not only cut their their their inference costs from opening ai but 70 by 75 times but they also um got the multi-agent architecture then for free i mean cheaper even out of the box because they were able to leverage these really uh well-tuned models so lost a couple in this story don't be sleeping on small language models they are here to stay all right let's move on from google we've given them enough attention let's talk about watertown the agent swarm data stack so what do we have here andrew yes this is a really fun article from jordan tigani it introduces watertown and jordan he works at uh he works at mother duck listen it's a database service is largely used for ai and friends vector stores but it's also just you know a database and he works with large amounts of data in this framework it takes yega's gas town idea and it maps it into eight stage progressions for data teams that are using it and it's a really fun article from jordan tigani and it introduces watertown and jordan there's a really cool article that talks about using ai automation starting from the very beginning of like automating sql assistance to having self-healing pipelines around querying and and manipulating data and it uses structured communication in really smart ways borrowing lots of uh techniques that steve has used to create his software factory now they have to have a data analysis factory um it's a really great glimpse at how people can adapt to this kind of methodology for their own use cases yeah there was a line in this article that like really stood out to me and made me chuckle a little bit and that is agents are like violence the only solution to the problems they cause is to use more of them and now i may not have used violence as the example but that line resonates with me extremely well you know because i feel like the challenges that we solve with ai only create additional challenges that can also be solved with ai and hopefully those new challenges are bigger and better challenges rather than just like dealing with the toil and the slop that that ai like that the poorly optimized ai can create so yeah there's this eight step maturity model for agentic use within data pipelines that is outlined in this article and i really think this is an exercise that we should be applying to most of knowledge work today so you know we do a ton of content production here at dev interrupted and i haven't really thought about a system for like leveling like where we are agentically within the group and you know we're doing a lot of research on how to move you know where we are agentically within the group and you know we're doing a ton of content another that.
We are definitely progressing deeper and deeper into agentic workflows.
But I think what makes these models particularly important is that they give you this maturity roadmap that shows you where you should be focusing next.
So you can see where you are now, but then also what the next step looks like.
So the types of things that you would need to build to achieve that step.
There's also another really great metaphor in this article, borrowing again from Steve Yege's ideas.
It's based on the book Master and Commander, I think, or something like that.
It's about basically how an agentic data pipeline operates sort of like a ship at sea.
So you have a log of observations.
You have orders that agents receive to do something.
There are flags that show when there's human feedback that's needed.
There's captains.
There's other roles within this ship that help maintain and build data pipelines.
There's also this metaphor about a scribe, which I also particularly love because I've used that exact metaphor myself in the past when building agentic content pipelines.
So yeah, you know, Andrew, I think you and I are both firmly in the camp of metaphors as being a really great way of conveying meaning to AI.
And it can be really powerful, like particularly if you can just really tie everything to that central metaphor.
So, you know, I love seeing these concepts getting applied to new fields.
And I think, you know, like other stories we're covering today, we're just going to see more and more of this as time goes on.
Yeah, I think that's a really good point.
I think that's a really good point.
I think that's a really good point.
I think that's a really good point.
I think that's a really good point.
I think that's a really good point.
It really speaks actually to not the whack-a-mole situation of using them as a solution, but actually rather just like the next order scale that you end up working on.
What it makes me think of is like, if you're going to go build a huge highway bridge over like a bay or a river, you're probably not going to use like hammers and nails and, you know, things by hand.
You're probably going to use power tools and trucks.
And like massive cranes and equipment to do it.
And you know what, when you bring those in, that is then not going to require more heavy machinery, more specialized people, more logistics.
And you might think like, oh, gosh, like, why couldn't they have just built it with, you know, hammer and nails?
And we all know the answer to that, to build like the sturdy thing that's going to be resonating and staying in the future.
We have to use the tool smartly.
And that means acknowledging that like, sometimes you got to put tools on tools.
But I'm strongly with you here on the idea of like, Gastown is coming to lots of different disciplines.
I think this is a great example of using it to create a semi-autonomous data working system.
And particularly what was really interesting to me is how it can flag these states for users and for humans that come in, almost like the human in the loop, but more like a human tool call that the agents can do to kind of get more information.
I think we're going to start seeing this pattern more.
I first learned about this, I think, it was last week when I was at human X, and I hosted a panel, one of the panelists, Angela McNeil of spread AI, she is there, they're the team that created Lemma, she made this really smart point about exactly that, that humans are evolving from being that in the loop to being like on the loop, or they are the loop, they're the tool call itself.
It's a really fascinating way of looking at it.
And it's really great to see it make its way into this example.
I love how people are adapting Gastown.
And I hope to see more of these.
All right, let's move on to our next one.
Stop calling it memory, the problem with every AI plus obsidian tutorial.
And I wanted to cover this one, because I feel like this is almost like a direct attack on me as somebody who recently became an obsidian convert because of agentic workflows.
But in this, this article, the author argues that obsidian markdown files as an AI memory in quotes, is a fundamentally flawed architecture that doesn't scale.
So you know, while obsidian works really well for us, it doesn't scale for us.
And so I'm going to talk a little bit about that.
For like personal notes, it fails as a data store, according to the author, because you can't query filter or handle relationships of that data at scale.
And in this article, the author argues that engineering teams need to use actual databases like SQLite for structured data, instead of flat files that get dumped into context windows, you should use proper infrastructure like Kuzu, OpenBrain, Supabase, you know, all the tools that help build these agentic systems, rather than using them as a database.
So I'm going to talk a little bit about that.
sort of hacking it with flat files in obsidian.
And, you know, like I said, I feel a little bit attacked by this.
But I also am not going to argue that a flat file system is with with like markdown and JSON is the most scalable system for when you need to do a whole bunch of agentic works, I'm not going to make that claim.
But for personal use, you know, I feel like or even for a small team, it is really often the quickest and easiest way to start building better context for your AI.
And, you know, and it's funny, Andrew, because I feel like you and I are sort of taking opposite directions on this often, like, you know, you've gone very like cloud centric, where all of your agentic workflows are triggered with stuff in the clouds that you can, you know, do it when you're like on your phone in the cab or working out in the morning or something.
Versus me, I'm going like pure local only with everything, like everything is now just a markdown or a JSON document that gets saved locally.
So I can just feed it into cloud desktop or something like that.
So what'd you think about this article, Andrew?
Andrew Walker As a heavy Obsidian user, I think that they really hit the nail on the head on how it can be used and what Obsidian really means for AI.
Because Obsidian existed, obviously, before AI came into the scene, note taking in this kind of way, locally on your machine with markdown files, with tags and links to each other in like a semi wiki way.
This is a really established way of building your own personal knowledge management system, something that I've been a big fan of even before.
I really love how this calls out the cargo cult thinking, and like the AI influencer space thinking that like, oh, wow, when OpenClaw came out, you know, they just had this like memory dot markdown file.
And this was the secret sauce.
This was why it was able to like, have this persistence to its memory and its capabilities.
But when you look closer, that's not actually the truth.
Like, one of the things being that not long after OpenClaw hit the scene and became viral.
They quieted down.
They quietly bolted on SQLite because of this exact reason.
You need the ability to query and fetch only what you need.
If you just dump a file into your context window, that's just brute force.
It's not retrieval.
There's no schema, no matter how beautiful your front matter is on your markdown.
There's no joins or traversals and your ability to scale that it actually comes a lot faster than you think.
And the Wiki links and stuff that link between them are great for humans.
They're great for human discovery, but they are not queryable.
You can, of course, create sorts of tools and stuff for an LLM to query it.
But then, you know, I'm just going to call it out.
Then you're just writing a database.
And so you should then just use a database.
Now, all of this said, there are very powerful ways to use Obsidian as a memory tool.
One of them being that if you use, for example, a AI focused plugin, there are a few.
There's like a copilot plugin for Obsidian.
You connect it with a subscriber token that you have.
It could be like from your favorite foundation model provider.
And the key here is taking those notes and embedding them.
These tools can actually take your notes and turn them into embedded semantic lookup of in like a local, basically like a vector database for your LLM to use.
This is the connector that you really need to make it more like a memory store.
However, I will say as someone who's used Obsidian every single day of my life for probably the last four years.
I don't use Obsidian at all in any combination with agents like you called out.
Like I work in the cloud.
I like to work in an ability where I can access everything from everywhere.
Talk to my phone or my terminal from any kind of place.
And that's what fits me.
Like right now I'm sitting in a hotel room.
I'm about to go spend the whole day at a conference.
Yesterday I was in a keynote and I shipped two things.
It's like the ability to work that way is only because I've taken the opposite things.
I don't want to be locked in my local machine.
The one other thing I will call out here is that like the unlock of taking things that matter to you and distilling them into a place where you can collect them over time.
And you and the agent can access them is absolutely critical.
And why I don't use Obsidian for this.
I certainly have tools and mechanisms for doing that.
So this will get you like 50% of the way there.
Just be mindful of how retrieval actually works.
And I don't just think that it's working on its own.
It's working on its own.
It's working under the hood.
You'd be surprised at how much you lean into the hallucinations of your agent when you think it's sitting on top of all your thoughts.
Yeah.
You know, in your approach, I'm not going to, you know, try to sugarcoat this at all.
Your approach is way more scalable than mine.
If you're like talking about scaling it out to a team or to your organization or putting it in production or something like that.
But I also don't really view what I'm doing with Obsidian as building memory when I record all of my artifacts into it.
Instead, I view it as more of a like a record of what I'm doing.
Like a record of historical context.
Right.
So instead of losing all that information to the ether, as I used to do, it all now gets captured in a single location that I can push to a Git repo.
I can feed directly into Claude desktop.
I can copy and paste files into whatever GPT service I might want to use instead.
And, you know, I think we don't really need to be focused as much on the tech that we use to solve this, especially in this day and age.
Like, it's really easy to use your agents to just migrate to new things.
To just migrate to new tech, particularly if it's something that you're just doing for your personal use.
So, you know, instead we should focus more on the process behind it all.
So if Obsidian is the thing that solves it for you today, then you should use Obsidian because it's a great tool.
But if you need to be more scalable, this article has some really great insights on how you can take it beyond just flat file architecture.
But, you know, I would actually bet that most people right now are not yet at a state where they need that level of scale.
And, again, the most important thing that you can do right now is start these practices rather than focusing on which tools you're going to adopt.
Bingo.
Yeah.
With all that said, I'm sticking with flat files on my local machine for now.
I was not convinced to change from this.
They just work so well for me and, you know, I can move really quickly and it's great.
But I also understand why this article exists and why some people out there might have issues with it as well.
All right.
Well, let's move on to from an article that says, Obsidian is the best way to do it.
The wrong answer to all this to the opposite.
An article that argues or that makes an argument for how you can use Obsidian in really great ways for this type of work.
So this article focuses on some recent learnings from Andrej Karpathy, who, you know, recently shifted from using LLMs for coding to building self-maintaining knowledge bases.
So he's spending more time manipulating tokens for knowledge rather than manipulating code itself.
And this article does a really great job.
Outlining a system that uses a two-tier architecture with raw sources and an AI compiled wiki that synthesizes and cross-links information automatically.
So talking about some of the relational challenges that we were just discussing.
And this sort of approach sort of is a little different from, you know, traditional note-taking practices because AI is doing all of the synthesis work.
And basically just removing a lot of the cognitive friction around understanding.
For listeners that don't know, Andrej Karpathy was one of the founding figures of the modern AI era and coined the term vibe coding.
And this article kind of breaks down a lot of the practices that he's been following recently.
It really resonates with how I feel.
Like, you know, I don't do a whole lot of code writing these days, but I do a lot of content, which has a lot of similar challenges.
And for the last four months, I feel like most of my time at Dev Interrupted and Linear B has been really just focused on code writing.
And I think that's really important.
Really just focused on the things that I want to convey rather than how I convey those things.
AI does all of the structuring and turning it into clear and actionable information.
But I'm the one that's there just giving guidance along the whole way.
And, you know, and just making sure that the AI stays on the right track and has all the information it needs to make the right decisions.
So what do you think about this article, Andrej?
Really cool piece.
I'm a big fan of Karpathy.
Follow all of his thoughts about how this space is evolving.
I really liked his idea of taking knowledge working tools that we traditionally use for coding and applying it towards knowledge working and knowledge maintenance.
And it's a really cool piece.
And Karpathy has invented a lot of, like, net new things.
But I will say, you know, Karpathy maybe didn't necessarily invent this way of building a tool or rather building a knowledge base.
What he's introducing here is like bringing, making it agentic, which is a really interesting level up.
But this goes all the way back to, like, Nicholson.
Zettelkasten.
Which literally means note box in German.
And Karpathy made the concept agentic.
And Luhmann, he was a prolific writer.
He wrote dozens of books in his life on a huge array of topics, was widely seen as just an incredibly bright, multidisciplinary person.
And the key to his secret and his prolific ability to write was this note-taking system.
That has a lot of callings back to what Karpathy did.
Yeah.
And Karpathy is built here.
He had a very specific notation and linking system on index cards, physical index cards, because this guy lived in, like, the 1800s.
And he used to produce, like, more than 70 books.
And we're talking, like, addresses, like, 1, slash, 1, slash, A, slash, 3B.
Like, the precursor of, like, a weird pigeon version of, like, a Dewey decimal system.
And he used this to organize knowledge and traverse it in a physical way.
And so what Karpathy is doing is taking those same techniques.
He's up-leveling it into a virtual agentic system and taking the compilation and the linking and the health checking and making these more streamlined with agents.
And so imagine 200 years ago using this by-hand note-taking system, using it to write more than 70 books, more than 400 articles in your life.
And now you're living in a modern age and you're able to do all of that same stuff but agentic at scale.
And these things can even, like, work and manipulate knowledge while you're sleeping or not at the wheel.
I think it's really fascinating because it's also a really great reminder that words do not equal knowledge, right?
Manipulating words on a screen and otherwise throwing tokens to get an inference result isn't necessarily in that form knowledge working.
Because an important thing to remember is that knowledge does not require language.
Someone can be in a business.
Someone can be in a business.
Someone can be unable to communicate via language.
There's lots of people who are unable to grasp or speak with language, but they still have a large amount of intelligence and knowledge working.
They just don't have the ability to express it.
And conversely, just because you can combine and move around words doesn't mean that it's actually logic and knowledge underneath.
Because words are a representation of symbols.
And symbols and symbol manipulation is where logic comes from.
Karpathy is using that to kind of create a knowledge.
A knowledge synthesis system.
He's using words as like a through pass to actually manipulate logic and build up information at scale using the connections between them.
And I actually relate with this a lot.
This is how I use cloud code quite a fair bit.
I'd say that like I use it, of course, for writing as a writing tool.
It's very helpful for that.
But I just have so many cloud code sessions where no code is written.
No article is outputted.
But we're taking ideas and cycling them around.
Rotating it.
Seeing it from a different angle.
Adding to it.
Stripping things out.
And this kind of surgical way of getting in with words and manipulating them to find patterns and knowledge is really powerful.
I definitely think there's a huge unlock in using Obsidian in this way and using any kind of knowledge working project.
So definitely people should be taking this kind of approach more seriously.
Because writing is the thinking.
And agents can create that map for you.
And allow you to then traverse and create those really incredible original thoughts.
Yeah.
The simplicity of the metaphor I think is what really makes this so powerful.
So it's kind of it's all centered around this idea that you basically have two directories.
You have raw and you have wiki.
Raw is just all of the raw assets that are being brought into the system.
And then the wiki is the AI taking those raw assets and processing them into some sort of refined component.
And I've been using a metaphor like this a lot lately actually.
I've been I've been calling it.
I've been calling some of the the agentic work that we've been doing sort of like running a like an ore refinery.
Like we have all this really raw resource coming into it.
And we have to process it into something that is more usable and refines like an ingot for example.
And it's very noisy while it's happening.
But if you do it right the thing that comes out the other end is this really nicely packaged thing that has a lot of uses.
But you know I mostly just love how this also kind of just contradicts the article that we just covered.
Because you know Carpathia also discovered that it doesn't need stuff like rag to search all of his documents.
You know in fact the LLM often does a really good job just with raw text files.
Particularly if you have some sort of index that is along with those text files that helps the AI determine which files may be relevant to a query that it's received.
And you know the article also points out how there's you know there's other similar tools out there like notebook LM that sort of solve similar problems.
Yeah.
But you know notebook LM.
It lets you like upload a bunch of documents.
And then you can like ask questions and use it to generate new assets and do all of that stuff.
But that's actually more of like a session based approach.
Like you're bringing all the context that you need for one challenge and then solving that one at a time before you move on to the next session.
What was outlined in this article is more of a systems level approach to doing that same thing for all of the things rather than just one effort.
And of course I love that there were some ideas in there about like using these tools to like create.
Automatic podcasts with the AI avatars talking to each other about the topic.
And you know I'll show our listeners out there that you know I'm a human still.
Andrew's a human.
Our producer Adam behind the scenes.
We're all humans.
We're going to stay humans.
For now.
We're going to stay humans.
For now.
No we're going to stay humans.
Y'all they will.
I can tell you right now they will drag me out of this podcast before they will put a virtual Andrew in it.
Yeah.
Well maybe we'll just switch me out and we won't tell you.
I don't know.
We'll see.
But you know.
But you know honestly I think what this article really points out it really helps solve is the challenge of keeping a system of record for all of the context but also injecting new ideas into that.
So you mentioned the Lumen method.
You know every relevant idea needs to be captured and brought into the system as an artifact so that it can be improved over time and it doesn't become stagnant.
AI is just not great at that like original thought that needs to be incorporated to improve a system.
That's right.
And you know and this article focuses mostly on writing but I do think there are many parallels between what is happening in the content production world and engineering right now.
Like we're solving very similar challenges with LLMs and we also have very similar roadblocks in achieving them.
So you know I think there's a lot of stuff that software engineering leaders could learn from this to help them improve their organization.
All right.
Andrew let's talk about the brain fry and how we can break out this AI spiral.
What do we have here?
Yes.
So friend of the show, past guest Kelly Vaughn has another article on After Burnout about how managing multiple agents creates this brain fry phenomenon in folks.
And that's you know a way to describe the mental fatigue from all of the context switching of course.
But just the different ways in which you have to think during your day in order to navigate through a day with agents.
She cites a Harvard study that found that overseeing AI tools is actually more mentally taxing than using them.
And I definitely have some thoughts on this that we'll get into.
And she gives some recommendations on how to protect your mental health while using these tools.
I think this is a really great reflection from Kelly who brings an incredible educated and unique perspective to engineering with her background as somebody in like therapy as well.
And so like understanding how these things impact your cognitive health.
Your cognitive health is really important to avoiding burnout.
Yeah.
It's another great article from Kelly.
She always is producing great content.
And I feel the pressure that she's talking about myself quite frequently to be honest.
You know and she had a really great description of how it feels.
You know every agent is essentially pinging you.
I need attention.
I need attention.
And all you're doing is context switching between them.
You know it sort of ends up feeling like you're less like an engineer and more like you're a manager of a team of engineers that you can't talk to.
And I think that last bit is really important.
Because you know since there's this distinct lack of trust you have to constantly validate and course correct these systems on pretty high level cognitive tasks.
And I have felt that brain fry that she describes on some days.
You know I've had days where I've done very high volumes of agentic work.
And I've produced a lot of things in a very short order of time.
And it's extremely difficult to use that.
It's extremely difficult to use your brain that way for an extended period of time.
You know I think Steve Yege mentioned this a while back.
He feels like he can only do that for about three or four hours a day before his brain really just starts to like not be able to focus in the right way anymore.
And Vaughn Kelly used a really great metaphor referring to your brain kind of like a plate.
Where if you want to add more stuff to a plate it doesn't make the plate bigger.
You just have to rearrange stuff.
And eventually you just run out of room on that plate.
And yeah so you mentioned some fixes.
She has a fairly simple fix that she proposes.
One of them is just stop watching what your agents are doing in real time.
Like you know it's really tempting to just watch all of the steps they're taking and analyze and be like do I need to stop them and course correct.
And maybe that's not the best way to do it.
Maybe we should just be more conscious of stepping away from the agent.
Letting it finish and then coming back when it needs the next step.
And then she also just recommends that you know.
If you feel like you're feeling brain fry at the end of the day.
You just need to sit and really think about what the things were that contributed to that in that day.
And try to find ways to just not replicate that in the future.
Like find ways to resolve that.
Find ways to find the focus time you need.
Or to step away from focus time to give your brain some time to recharge.
So yeah definitely go check this out if you feel like you're a little overwhelmed by AI.
I think the thing that stands out to me is this definition from the Harvard Business Review that she or the Harvard study that she cited.
About what is really the biggest takeaway.
It's not that it's using AI fries your brain.
It's overseeing it.
And that distinction is really important.
Because in the last several months many engineers have been taking these steps from individual context collaborations with agents.
Or single threaded conversations to managing and orchestrating agents at scale.
And this isn't like.
Oh I threw in three more agents.
So I'm just doing three times the amount of cognitive load.
It's actually more like you're doing a cubed amount more cognitive load.
Because you're thinking about it across all of the surface areas that they're working.
And the more that you throw into it.
And kind of like stare at it.
The harder it is for you to pull away and do anything else.
And I've definitely seen stories from founders.
You know citing problems with sleep or insomnia or focus issues.
That really only started to kick in.
After working with agents this way.
Like you greatly cited.
Yege had an entire article on avoiding AI burnout through using Gastown.
The very orchestration system that went viral at the top of the year.
Because he himself was feeling it.
And I see these candid stories from folks.
And I really resonate with it.
I can't see for myself that I've fallen into this trap of.
Or into this situation where it negatively impacts my ability to focus.
Or to even sleep.
I do agree that sometimes it can be hard to peel away from the terminal.
When it's in the middle of a session.
I do like to watch and monitor what my agents are doing.
At least at some stages of certain tasks.
And if you find yourself in this position.
Oh I have to watch them.
Oh I have to course correct.
My challenge to you is to figure out what you're watching for.
And bake it into a skill.
Because that's ultimately what I was able to do.
To scale up my practice.
And my agents know very specifically.
The order and the flow of operations in which I work.
To the point where I can just kind of spew ideas at it.
What I want.
And I can trust that the system is going to rightfully create a spec.
And then rightfully review it with another third party agent.
And then create some tests right before it's going to go write code.
And so I know that once I kick off that process.
There's actually a lot of steps that the agent's able to do.
Without me interfering at all.
Where I can turn away.
And I can go focus on something else.
And I think getting to that point is how you avoid the fry.
Yeah well coming back to the story we covered earlier.
Agents are like violence.
The only answer to the problems they create is more agents.
More deterministic checks.
Or just I mean honestly this goes back to like.
For me it reminds me a lot of like classroom management.
Like okay you have a homeroom.
And then like what you got to be sick.
Or you're going to be out for a day.
And then like you're out.
You're thinking like oh god.
What are my students doing to the substitute teacher?
Are they learning?
Are we going to be behind on our module?
Like there's so many.
There's so many things that go through your head.
But if you're a teacher that creates systems.
And skills.
And support systems.
And support methods.
For that substitute teacher.
To actually like step in and be that helper.
And also for your agent.
For your agents.
For your students.
To be able to know like oh gosh.
If Mr.
Ziegler was here.
What would he tell me to do next right now?
You know what would he tell me to.
How would he tell me to move forward with this?
Like the more that you could put that in someone else's mind.
About how you would act in that situation.
The less that you're going to feel like you have to monitor.
So that's what this reminded me a lot of.
Was the fun of like having my first absence as a teacher.
And then being like oh god.
This is like more stressful than just like I wish I was at the school.
And so definitely a lot of techniques to take away here.
Prompt and forget it.
Is a really powerful one.
Everyone should be striving to get there.
And if you haven't been.
If you haven't subscribed already to After Burnout.
Please go do so.
Because Kelly writes these really great deep dives.
On how to protect yourself in the agentic era.
Absolutely.
All right Andrew.
So what violence are your agents up to right now?
Well as you may have noticed.
I'm at TDX.
And I'm in my hotel room right now.
So between the sessions.
Being on the floor.
Getting really cool tours.
Of all of the developments from Slackforce.
I've definitely been talking with my agents.
As you all know.
I roam with them.
And I talk with them on my phone.
Because I work via a terminal or a remote machine.
So while I was in the keynote yesterday.
I worked on two of my agents.
They unveiled a lot of really cool stuff.
Around agent force.
Headless tools that you can use.
To create tools in Salesforce.
Like using cloud code.
Instead of just like proprietary Salesforce tools.
That they had before.
The really cool thing I'm taking away from this.
Is all the Slack bot innovations.
That they've come up with.
They're really making the bet.
That you know where your chat happens.
Is where the AI is going to happen to.
And I strongly strongly agree.
Even just like two years ago.
I gave this talk on multiplayer AI.
In a chat program.
And what that would look like.
The trust problems.
The managing a shared context.
How you would pass that information back and forth.
And I was exploring that.
You know two three years ago.
So it's fascinating to see Slack finally meet the moment.
And become this like agentic operating system.
For people and their agents to solve problems together.
So a lot of really cool demos.
So really excited to be on site here.
Yeah.
You know if people say flat files.
And local stuff is not scalable.
Slack is probably also not scalable as well.
But it is quickly.
I mean it is becoming sort of like a central hub.
For agent interactions.
For gathering information.
For doing research.
I mean it actually is a pretty powerful place.
I mean we have a lot of agents.
We have more and more agents.
That are showing up in Slack.
In our own Slack.
And it seems to be the place where.
It's kind of the central hub of activity.
You know.
Yeah.
Well if you can push back on that a little bit.
I'll say that Slack can scale.
Slack is where the work happens.
Where the chat happens.
It doesn't have to be Slack.
It could be anything that you're using to communicate.
But your communication tool is.
You know it's always going to scale.
With your company.
That's why teams of three people can use Slack.
Just like teams of 10,000 people can.
Yeah.
Yeah.
And you know it's kind of like.
The challenge of like.
We do need a system though.
Of like.
In the same way that we need to have.
To be able to go from like flat files.
To like.
You know.
A more robust system.
I feel like Slack is going to have to go on a similar journey.
Right.
Because we.
I think we want to use our Slack.
For our agents in ways.
That it's not really optimized for yet.
And I think there's tons of potential for that.
But yeah.
And that's where.
I think my agents are really kind of focused right now.
Like you know.
We've been doing a lot of stuff.
To sort of roll out our agents to other teams.
That haven't had as much exposure.
To this level of work yet.
And it's all happening.
Over our chat system.
You know.
Yeah.
So it's pretty.
Pretty exciting times.
Because you know.
A lot of cool things are.
Are happening.
Because of that.
Indeed.
All right.
Well that's the Friday.
Deploy.
From Linear B.
Thanks everyone.
For joining us this week.
And we'll see you next week.
See you next time.
AI is everywhere in software engineering.
But most teams still can't prove its impact.
That's where the APEX framework comes in.
APEX is a new operating model for software engineering.
APEX is a new operating model for software engineering.
APEX is a new operating model for software engineering.
APEX is a new operating model for software engineering.
APEX design to measure AI where it actually matters at the pull request level it.
Connects AI activity to delivery outcomes.
Not just.
Tool usage.
APEX is built on four pillars with AI leverage.
Predictability.
Efficiency.
And developer experience.
APEX helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.