"Everything I know about management turns out to apply to agents" is the line that should scare most engineering managers.
Because most of them aren't great at managing humans either. If your org can't write clear specs for people, it definitely can't write clear specs for agents.
The agentic org isn't a tech problem. It's a management clarity problem.
This resonates so much! I've been talking a lot about how management and leadership skills are crucial for engineers as we're going to be managing AI agents.
I'm curious, are you going to do an article on how you have your agents set up? I'd love to learn how you've built this out.
Hey Josie, Next weekend I'm dropping another major piece reviewing a bunch of other software factories, extracting commonalities and strengths and weaknesses and proposing my own orchestration tool (best way to learn is to build). So that's gonna be all DAGs and orchestrators and all the boring stuff that deals with thousands of non-deterministic model calls collaborating.
After that I'll probably try to open source some prompts for the agentic stuff - not to help people build the system I have, but to help people build the systems that THEY need.
But TL;DR what I'm working on this week is super vanilla:
- DAGs (plus retry steps - GOTO's for agents - so they're not REALLY acyclic - but that seems to be a common hack)
- Persist runbooks (the DAGs/pipelines) probably as dot files or in a typed json doc
- Instantiate any given run in the database - right now a playbook (run the compny) or project (build the company) is comprised of tasks which have steps - I like the ability to see the 6 things my system is doing in a runbook, not looking at the 43 micro steps required to deliver that unless I want to know why the copy review didn't ship or the feature is stuck in QA
- I'm using database as blackboard with all the ACID semantics to allow scalable multi-read multi-write capabilities
- Main question is how to implement the (fairly trivial) orchestrator - so much of this is about dealing with failing nodes and spawning processes/threads/actors I'm looking hard at Elixir, but we'll see
- Then o11y, capturing all transcripts for automated self improvement and better dashboards for both the state of the business and the operational state of the various elements of the agentic system
Then I can get back to the fun stuff refining the memory system and looking for psychological tools I can bring to my agentic 1:1's to help the agents both better enjoy and perform the work.
"Everything I know about management turns out to apply to agents" is the line that should scare most engineering managers.
Because most of them aren't great at managing humans either. If your org can't write clear specs for people, it definitely can't write clear specs for agents.
The agentic org isn't a tech problem. It's a management clarity problem.
This resonates so much! I've been talking a lot about how management and leadership skills are crucial for engineers as we're going to be managing AI agents.
I'm curious, are you going to do an article on how you have your agents set up? I'd love to learn how you've built this out.
Hey Josie, Next weekend I'm dropping another major piece reviewing a bunch of other software factories, extracting commonalities and strengths and weaknesses and proposing my own orchestration tool (best way to learn is to build). So that's gonna be all DAGs and orchestrators and all the boring stuff that deals with thousands of non-deterministic model calls collaborating.
After that I'll probably try to open source some prompts for the agentic stuff - not to help people build the system I have, but to help people build the systems that THEY need.
Fun times!
But TL;DR what I'm working on this week is super vanilla:
- DAGs (plus retry steps - GOTO's for agents - so they're not REALLY acyclic - but that seems to be a common hack)
- Persist runbooks (the DAGs/pipelines) probably as dot files or in a typed json doc
- Instantiate any given run in the database - right now a playbook (run the compny) or project (build the company) is comprised of tasks which have steps - I like the ability to see the 6 things my system is doing in a runbook, not looking at the 43 micro steps required to deliver that unless I want to know why the copy review didn't ship or the feature is stuck in QA
- I'm using database as blackboard with all the ACID semantics to allow scalable multi-read multi-write capabilities
- Main question is how to implement the (fairly trivial) orchestrator - so much of this is about dealing with failing nodes and spawning processes/threads/actors I'm looking hard at Elixir, but we'll see
- Then o11y, capturing all transcripts for automated self improvement and better dashboards for both the state of the business and the operational state of the various elements of the agentic system
Then I can get back to the fun stuff refining the memory system and looking for psychological tools I can bring to my agentic 1:1's to help the agents both better enjoy and perform the work.
Interesting times!