I.
Claude Tag; a version of Claude that lives inside a Slack channel and works asynchronously, the way a member of the team would. This newer interface is focused more on the permission model. Claude Tag runs under what Anthropic calls an “agent identity” where it acts through its own service accounts rather than borrowing one person's login, channel work bills to the organisation while direct messages bill to the individual user, and admins scope which channels and tools it can touch. For years an agent was an extension of you, running on your key, your seat, your account and in that way, it made agents extremely powerful, but now extremely limiting. An agent identity makes it easier with its own credentials, its own spend, and before long its own subscriptions (probably). I think most of the next few years of AI happen within this new paradigm, and it will have increasingly less to do with the models themselves. This generation of models are already strong enough for the work; Opus 4.8 will write most of a feature if you let it off the leash. The movement now is in the ecosystem around the model like how agents get an identity, how they get handed work, and where their output runs and gets checked. The model was this behemoth of a research problem and I feel that as of today, it is mostly solved. That is to say, if GPT 5.5 and Opus 4.8 were the last iterations of LLMs, I feel as though we could still accelerate AI in the workplace and AI at an individual level. And I think that engineering has moved one layer out, and it is going to keep moving out layers at a time until the agent stops feeling like a tool you operate and starts feeling like a thing you delegate to. I would venture to say Ultracode via Claude Code is an example of this. You give an orchestrator one prompt and it delegates, validates and returns a (hopefully) working product demo. But it is still limited, and in this essay/blog I want to give my thoughts on ways the ecosystem can change to fill in these gaps.
II. Identity
Give an agent its own accounts and the relationship inverts. A tool is something you hold; a principal is something you hand things to. An agent with its own spend and infrastructure can hold its own subscriptions. An agent with its own subscriptions can sign up for the services it needs to finish a task without laundering everything through your credentials. And once an agent is able to do that, the possibilities in my view are only limited by what other companies are willing to provide as “Agent First” products. I think this is the way forward, more than any single model capability jump. The reason most people have not folded AI into their day-to-day flows is not that the model is too weak. Even older generations of models such as GPT 5, Opus 4.5, etc. have indeed shown the opposite. It is just that "open a terminal and supervise a session" is not a workflow they recognise. Handing a task to a coworker is familiar though. And an agent identity is what lets the second framing be literal instead of a metaphor, but currently the ecosystem lacks the maturity to provide that robust framing.
III. The teammate, not the terminal
Most people inside any company will never want Claude Code's TUI, and they should not have to. The fancy interface is built for people who already live in a shell, and that is a small slice of any organisation. Everyone else is fluent in a different interface that predates computers entirely: you describe what you need, you pass it to a person or a team, and it comes back, done to the standards set by the organisation. So, Anthropic is pitching Claude Tag almost exactly this way, as more of a standing member in a channel you can assign work to. Internally, they claim it creates around 65% of its product team's pull requests (Obviously they may be biased towards themselves to market the tool but I think there is some truth to it). Building off that, the floor for entering software engineering rises. Vibe coding lets someone with shallow expertise ship working code, which means more people clear the bar for the "sit down and ship things" kind of engineering than ever did before. Generally that is a good thing. Just the other day I showed my mom how she can make a small web app that allows her to save and rewatch her favorite recipes. The democratisation of “building” is a good thing. However, it also means that the scarce, durable work stops asking "can you produce code?" and becomes "can you tell whether the code an agent produced is safe to run?" When the floor rises, value moves to whatever is still hard above it. In that way I do not buy that “AI will replace all engineers within the next 6 months.” I do, however, think the meaning of engineering will change. The roles will change, but for the better, I hope.
IV. The work now moves to validation
On that subject of roles shifting, we still do not have a good way to validate what agents write. We have tests, we have code review, we have linters, but none of it was designed for a world where the author is a model that will happily generate ten thousand lines overnight and cannot be asked, later, what it was thinking. I think about my own workflows where Claude can write 5k lines of code, and I mostly spot check areas I know can cause issues, but let’s be honest, there’s no feasible way for me to review all 5k additions within the day without burnout. Hence why traditional software development has required time. And so the centre of gravity for skilled work shifts toward the parts that were already about trust at scale: MLOps, DevOps, and the unglamorous art of giving agent output somewhere safe to run (sandboxes my beloved). And when it comes to sandboxes, forward thinking companies are on it. Daytona recently raised $24M and rebuilt itself around exactly this problem, sandboxes that boot in under 90 milliseconds so an agent can spin up a real computer, fork it into thousands of parallel instances to try different approaches, snapshot it, and throw it away, all through an API with no human in the loop. Their pitch is that the cloud we have was built for humans serving stateless production traffic, and agents need a cloud built for branching, exploratory, stateful work instead. Modal is coming to the same conclusion from the serverless side, with isolated sandboxes that can run up to 24 hours and scale past 50,000 concurrent instances, and is already running millions of executions a day for products like Lovable and Quora. Once the flywheel gets spinning, hundreds of agents shipping code into sandboxes around the clock, you need a team standing by for when it fails, because it will, because LLMs are non-deterministic and even a subtle prompt change will throw the whole agent loop off track. The romantic version of agentic engineering is the run that produces a working feature, first try, all the time. But the version we have today (at its best) is a run that produces a confident, plausible, broken one, at a volume no human reviewed in time. The people who can catch that before it reaches production are going to be worth more.
V. You still have to know how to code
This is why I keep saying that learning to code matters more now. You can get a long way vibe coding, but you cannot tell where the weak points are/going to appear unless you understand what is being written, and I think understanding the weak points is going to become the entire job once the model is off on it’s own I am my own example. I started coding in middle school and I am still learning whatever I can; right now that is Swift, and Go, which I am not doing especially well at. I review what agents write for me, and to my dismay, probably not as carefully as I should. But that’s because none of my projects serve hundreds of millions of people, so the cost of missing something is close to nothing. The only impact is myself and my time. But that mentality has to go away as I scale to serve other people. Because then it is on me to provide a service that is reliable. And as we move toward letting agents run unattended for hours (for some crazy people, even days), the difference between someone who can read and understand the diff and someone who can only prompt for it becomes the difference between catching the failure before it hits prod and shipping a shoddy product.
VI. Individual use at scale
Claude Tag and other enterprise offerings (I’m sure OpenAI has @GPT) around it solve org-level deployment. Claude Code on your own machine solves individual use, you and your account and your session. Nothing I know of solves individual use at scale: multiple people orchestrating many agents, pooling context across them when that helps, walling it off when it has to and letting other people bring their own setups into the same space without their work bleeding into yours. That is what I am building Beckett (https://beckett.frgmt.xyz) toward. I want a place where I can work agentically, mostly review rather than write in a space I am familiar with, and let my friends use their own agents and context alongside mine without interference, while still sharing a codebase when the work calls for it (wow what a sentence). The thing I’ve yet to find implemented well is shared context with clean separation. So agents from one person and one provider cannot collaborate with another person's agents on the same codebase when the two live in entirely separate places. Something like typer (https://typr.frgmt.xyz) is what agents can build when you point them at a problem, and a reminder that they build in isolation by default, one operator, one walled garden at a time. No one can access my codebase without pulling the repo from github, building on their own infrastructure, then filing a PR. This method, while traditional, loses all the synchronous collaboration. Beckett is very early, and I suspect the reason it does not exist yet is not that nobody clever has thought of it, I’m sure plenty of people have. They just have not built it. And I suspect I will not be the only one building toward this for long, and I hope I am not, because the ecosystem gets to flourish only when more than one person decides the interesting work is no longer on the model.