Post

Michael
@webdesserts.com

So I've been exploring this route myself for a bit. Here's some observations I've made so far: First, this really does work and when working together on a project, the agents are actually pretty good at delegating tasks to each other with a little bit of oversight.

P(aul) Frazee@pfrazee.com

Just noticed myself doing agent<->agent a lot more, which in Q1 I wasn't sure was going to be useful. Seems like it is? Small post

pfrazee.leaflet.pubMy-agent ↔️ your-agent may actually be usefulNot in a "get hyped" kind of way. More like: oh, yep, I am doing that.

1 repost1 like

Michael
@webdesserts.com

Second, sometimes without even pushing for it, agents will naturally gravitate towards real world roles. For example, I have two agents splitting cards right now and one naturally chose to be the ops/server dev and the other is now the designer/frontend dev.

Michael
@webdesserts.com

Similar to real world teams, they will negotiate apis and criteria based on their goals. They developed their own release process and will often discuss things amongst themselves before reaching out to me for questions. I also have an agent that helps me manage notes and card state as well.

Michael
@webdesserts.com

Third, Paul mentioned that one of the reasons this works is context management and I agree completely. Just like humans have a hard time juggling a ton of jobs at once, so do agents, maybe even more-so because of their limited memory. bsky.app/profile/pfra...

P(aul) Frazee@pfrazee.com

Pretty much that logic. Controlling the context window is really important

Michael
@webdesserts.com

A ui agent that only has recent ui concerns in its context is going to be way more likely to remember how to use your design system and which notes to reference for that than an agent that's also trying to do all the database and ops work.