Agents Are Not One Thing - Jelmer SnoeckAgents are not one thing. They come in at least three archetypes, and the trust boundary scales with what each one is for: personal, team, autonomous. Each one demands a different identity story, a different audit story, a different credentials story.<br>The industry talks about &ldquo;agents&rdquo; as if they&rsquo;re one archetype. They&rsquo;re not. And the cost of pretending they are shows up the first time a research agent gets a personal GitHub token and decides to be helpful.<br>I run several agents in my daily work, and they fall into three archetypes: personal, team, autonomous. They share an LLM call at the core and almost nothing else.<br>Personal: the agent that knows your inbox<br>The personal agent is tailored to the end user. It reads their calendar, their email, their tickets, their PRs, and it builds context the way a good chief of staff would, except it does so before the user&rsquo;s first coffee.<br>Mine is called catchup. It connects to Google Calendar and Gmail, Slack, Granola, Linear, and GitHub, and every morning it produces a brief covering what happened overnight, what needs my attention today, and what&rsquo;s coming up. The brief matters more on the days I&rsquo;m not at full attention. I&rsquo;m on parental leave right now and working part time, which means a Monday morning involves catching up on three or four days of email and chat across a team that didn&rsquo;t stop, and I do not have the time or the focus to grep through that by hand. The meetings get per-event prep, so every conversation, email, PR, and ticket related to the meeting is surfaced before I walk in.<br>This is the easy end of the trust spectrum, with a single principal whose data the agent reads and a blast radius bounded by the surfaces I already own. The temptation, given how contained that feels, is to give the agent your personal API keys and call it done. People do it, and for a while it works. I built catchup on Keycard from day one instead, not because I was being disciplined but because I work at Keycard and I knew where this was going.<br>The real cost of personal API keys is that they make the agent single-tenant by construction. The key belongs to one person, the agent serves one person, and that&rsquo;s the entire universe the design can imagine. It works fine until the day someone else asks whether they can have it too.<br>The answer at that point is usually &ldquo;sure, give me a week,&rdquo; because going from single-tenant to multi-tenant is not a configuration change but a rewrite. The credentials were never scoped to a user, they were scoped to the user, so there is no user dimension to peel out, no audit trail of who-saw-what, and no way to revoke one person&rsquo;s access without revoking everyone&rsquo;s. The fact that the code accidentally works for one user is not the same as the code being ready for two.<br>If the agent was built multi-tenant from day one, with credentials minted per-user against a real identity system, adding the second user is a configuration change and adding the tenth is the same operation as adding the second. This is why the framework has to bite at the personal end, not because the personal blast radius is large, but because the personal stage is the only window in which the architecture is still cheap to choose.<br>Team: the agent that does the work the team forgets<br>The team agent is shared and produces outputs the whole team consumes. It runs on a schedule, touches systems the team collectively owns, and acts on behalf of the team rather than on behalf of any one person.<br>Mine is an ops-review agent. Once a week it pulls Datadog data, categorizes the incidents and pages and errors that fired, and produces an overview of where the system spent its budget of attention. Without it, the weekly ops review is a chore where someone has to grep dashboards and assemble the picture by hand. With it, the review starts from a tight summary and the time goes to the interesting question of what we change.<br>That single shift in archetype changes everything about the trust story. There is no longer a single principal but a rotating set of humans whose only common identifier is the org, and the blast radius is no longer my own surfaces but whatever production telemetry the team can see, and by extension whatever production reality the team can act on.<br>Personal API keys do not work at this point; they never did, but at the personal end you could pretend, and at the team end the pretending fails immediately. Whose Datadog key is it, and when that person leaves does the agent stop? When the agent reads a customer incident, whose audit trail records the read? If the agent&rsquo;s credentials leak, who is accountable for the rotation?<br>The team agent needs its own identity, not a borrowed one. It has to be a first-class principal that the team grants access to in its own right, and from there it has to be able to act on behalf of individual team members when the task calls...