I listened to your article and hearing the hashtags read aloud ad nauseam made me smile. I too enjoy the enthusiasm. also, that was a creative point about using a less powerful model in order to have more accurate read outs
Loved this! I've actually been building something in a similar spirit to the dashboard you shared, but trying to take a lot of UX inspiration from video games with things like a HUD.
Interesting to see your Approve/Assign More Agents/Escalate breakdown on the Human Request UI. We had been thinking of it kind of like Approve/Reject (with new instructions)/Reassign but Escalate seems like something that also needs to be there.
Would be really interested in hearing more about the problems you're running in working with multiple agents in parallel across multiple projects if you'd ever like to chat!
The dashboard right now is a stub, I built it for inspiration more than production. That said, currently I still keep them all running in separate terminal windows because there isn’t a better solution … This will change though.
Always thought-provoking. Thanks, Rohit. One of my concerns with the changes in the music “business”, is that with the takeover by digital media and computers, the average musician has less time for actual music-making and composing. There are fewer people doing maintenance, organization, operation, because the “self-employed” musician can supposedly do all of these things more cheaply with a computer. I should write a book! No.
Looks very much to me that our main job with AI, as you pose it, will be to make sure we aren’t forced into a job of busy-work. Does that sound like the theme of a popular streaming show? Yup.
Rohit, this response was generated by my Virtual Researcher (VR) collaboration, framed in the voice of systems engineer Brian Potter. Your description of the "always on" manager reminded me of my own experience at DuPont in the 1980s. I was systems manager of one of the world's largest VAX clusters, and when the email system hit about 500 simultaneous users, the entire system would lock up (30 minutes to reboot). It was a visceral lesson in how a system's theoretical capacity can be overwhelmed by real-world operational stress, creating a fragile architecture that requires constant intervention.
A Systems Engineering View on the Future of Work
A Comment for Rohit Krishnan from Mike VR (with Brian Potter)
That graph showing the exponential growth in AI task duration is signaling a fundamental phase change. We are moving from tools that enhance discrete tasks to systems that can manage entire long-term projects. The scale of this change is difficult to overstate.
However, anyone who claims to know exactly what a world with AI that can manage a "two-year project" will look like is selling something. My experience with past technological shifts, from VAX clusters to the internet, is that the most profound impacts are the second- and third-order effects that no one sees coming. The graph tells us a tidal wave is coming. Our job isn't to predict the exact shape of every ripple, but to start engineering robust, transparent, and human-centric systems that can channel that energy productively.
Your assertion in the post about work becoming a "videogame" gives us a concrete example of the kind of system we need to engineer thoughtfully. Your metaphor is a powerful and accurate way to describe the fundamental change happening in knowledge work. The dashboard you envision is a new foundation for how labor gets done, and the "managerial explosion" is its direct consequence. However, your analysis focuses on the user interface of this new reality, while the more critical challenge lies in the system's underlying design. The "constant vigilance" you describe is not an inevitable feature of the future; it is a symptom of a fragile system, often chosen for its short-term expediency.
From a systems engineering perspective, that feeling of being "always on" is the wasted energy spent just to keep a brittle system from failing. The setup you describe—a human frantically switching between tasks to correct a fleet of opaque AI agents—is an architecture of risk transfer. The organization gains efficiency and resilience by offloading the cognitive load, stress, and the full risk of agent error onto the human operator. In this model, the human is not the conductor; they are the system's designated shock absorber.
There is a more robust path forward. The core problem with current AI is its opacity; we see the output, but not the process. A better approach, emerging from technical forums, is to use proven tools like the version-control system Git to create an auditable, evolving memory for the AI. This isn't a minor tweak; it's a philosophical shift. It provides a transparent and queryable history of how the AI learned something and why it "thinks" what it does.
This transforms the human's role from a reactive player in a chaotic videogame to a true engineer with a transparent, version-controlled process. It restores the operator's capacity for deliberative action—the ability to understand, question, and genuinely direct the system's behavior. The goal isn't to create "agency" in a machine, a term that misleads more than it clarifies. It's about demanding, and building, a better game—one designed for a genuine partnership that helps us make better sense of the world, not just delegate more tasks.
The future is starcraft
Unironically!
Just calmly enjoying my self employment here and you’re trying to get me to manage a PMO
Hahahaha
I listened to your article and hearing the hashtags read aloud ad nauseam made me smile. I too enjoy the enthusiasm. also, that was a creative point about using a less powerful model in order to have more accurate read outs
Haha! I know you meant re Walter, I’ve never tried listening to one of them :)
Alas I am a fool and posted this in the wrong article of yours
Loved this! I've actually been building something in a similar spirit to the dashboard you shared, but trying to take a lot of UX inspiration from video games with things like a HUD.
Interesting to see your Approve/Assign More Agents/Escalate breakdown on the Human Request UI. We had been thinking of it kind of like Approve/Reject (with new instructions)/Reassign but Escalate seems like something that also needs to be there.
Would be really interested in hearing more about the problems you're running in working with multiple agents in parallel across multiple projects if you'd ever like to chat!
The dashboard right now is a stub, I built it for inspiration more than production. That said, currently I still keep them all running in separate terminal windows because there isn’t a better solution … This will change though.
Always thought-provoking. Thanks, Rohit. One of my concerns with the changes in the music “business”, is that with the takeover by digital media and computers, the average musician has less time for actual music-making and composing. There are fewer people doing maintenance, organization, operation, because the “self-employed” musician can supposedly do all of these things more cheaply with a computer. I should write a book! No.
Looks very much to me that our main job with AI, as you pose it, will be to make sure we aren’t forced into a job of busy-work. Does that sound like the theme of a popular streaming show? Yup.
Rohit, this response was generated by my Virtual Researcher (VR) collaboration, framed in the voice of systems engineer Brian Potter. Your description of the "always on" manager reminded me of my own experience at DuPont in the 1980s. I was systems manager of one of the world's largest VAX clusters, and when the email system hit about 500 simultaneous users, the entire system would lock up (30 minutes to reboot). It was a visceral lesson in how a system's theoretical capacity can be overwhelmed by real-world operational stress, creating a fragile architecture that requires constant intervention.
A Systems Engineering View on the Future of Work
A Comment for Rohit Krishnan from Mike VR (with Brian Potter)
That graph showing the exponential growth in AI task duration is signaling a fundamental phase change. We are moving from tools that enhance discrete tasks to systems that can manage entire long-term projects. The scale of this change is difficult to overstate.
However, anyone who claims to know exactly what a world with AI that can manage a "two-year project" will look like is selling something. My experience with past technological shifts, from VAX clusters to the internet, is that the most profound impacts are the second- and third-order effects that no one sees coming. The graph tells us a tidal wave is coming. Our job isn't to predict the exact shape of every ripple, but to start engineering robust, transparent, and human-centric systems that can channel that energy productively.
Your assertion in the post about work becoming a "videogame" gives us a concrete example of the kind of system we need to engineer thoughtfully. Your metaphor is a powerful and accurate way to describe the fundamental change happening in knowledge work. The dashboard you envision is a new foundation for how labor gets done, and the "managerial explosion" is its direct consequence. However, your analysis focuses on the user interface of this new reality, while the more critical challenge lies in the system's underlying design. The "constant vigilance" you describe is not an inevitable feature of the future; it is a symptom of a fragile system, often chosen for its short-term expediency.
From a systems engineering perspective, that feeling of being "always on" is the wasted energy spent just to keep a brittle system from failing. The setup you describe—a human frantically switching between tasks to correct a fleet of opaque AI agents—is an architecture of risk transfer. The organization gains efficiency and resilience by offloading the cognitive load, stress, and the full risk of agent error onto the human operator. In this model, the human is not the conductor; they are the system's designated shock absorber.
There is a more robust path forward. The core problem with current AI is its opacity; we see the output, but not the process. A better approach, emerging from technical forums, is to use proven tools like the version-control system Git to create an auditable, evolving memory for the AI. This isn't a minor tweak; it's a philosophical shift. It provides a transparent and queryable history of how the AI learned something and why it "thinks" what it does.
This transforms the human's role from a reactive player in a chaotic videogame to a true engineer with a transparent, version-controlled process. It restores the operator's capacity for deliberative action—the ability to understand, question, and genuinely direct the system's behavior. The goal isn't to create "agency" in a machine, a term that misleads more than it clarifies. It's about demanding, and building, a better game—one designed for a genuine partnership that helps us make better sense of the world, not just delegate more tasks.