--- title: "Identity and Agency Are Deeply Interconnected" canonical: https://workspace.socra.com/blog/engineering/identity-and-agency-are-deeply-interconnected author: "Socra" published: 2026-11-06 updated: 2026-11-06 --- # Identity and Agency Are Deeply Interconnected Imagine everyone on your engineering team used your account to do their work. They opened pull requests with your credentials, changed documents under your name and inherited access to everything you could access. What would that mean for your team? You could give each person a different job, and they could work independently throughout the day. But whenever they interacted with your systems, those systems would see you. Understanding who changed something would require another record somewhere else. Giving one colleague less access would require restrictions beyond the permissions on the account. Removing their access would mean finding every place they could still use your credentials. We already understand why people need separate accounts when they work together. As agents take on ongoing responsibilities, the same reasoning applies to them. ## Agency depends on who is acting An agent can decide how to approach a task, use tools and continue working without instructions for every step. When we talk about agency, we usually talk about those capabilities. But every action also happens under an identity. When an agent reads a document or changes a system, the service receiving that request needs to determine who is asking and whether that actor has permission to proceed. Let’s say you give an agent responsibility for maintaining your support articles. It needs access to the articles and the product knowledge required to keep them accurate. You might also have access to billing settings and private company information because your own responsibilities are broader. If that agent authenticates as you, the receiving service evaluates the request against your identity. Instructions can tell the agent to stay within its assignment, and additional controls can restrict what it does. The underlying account still belongs to you. With its own authenticated identity, the agent can receive access appropriate to its responsibility. The service can evaluate what that particular agent is allowed to do, and the work can be attributed to the same actor that performed it. **Identity and agency are deeply interconnected because delegated responsibility needs an identifiable actor who can exercise it.** The team decides what an agent may take responsibility for, and the systems it works with recognize the agent exercising that authority. ## An identity on a team A technical identifier gives a system a way to recognize an actor. A teammate’s identity develops through its place in the organization. Consider a colleague responsible for maintaining a product. Their identity within the team includes what they know about that product, which decisions they can make and the people who depend on their work. Their record matters too. Over time, the team learns which responsibilities they handle well and where they need help. We apply that understanding to CoAgents, Socra’s AI teammates. Each CoAgent has its own identity within the team, a role and responsibilities. It acts under its own name with the access the team gives it. People can assign it work, give it feedback and change its responsibilities as the team’s needs change. Its identity is relative to that team. A name helps people recognize it, while its responsibilities and relationships explain who it is to the people working alongside it. This is what we mean when we say a CoAgent acts on its own behalf. The organization still sets its authority and holds responsibility for how it is used. Within that authority, the CoAgent acts as the identifiable member carrying out the work. ## How Socra represents that identity To make this concrete, we need to follow the identity through the system. When Socra provisions a CoAgent, it creates a distinct Agent principal within the team’s Account. A principal is the identity a system uses when deciding whether an action is allowed. The CoAgent retains a reference to that principal as part of its persistent record. When its runtime needs access to Socra, the platform requests a token for the CoAgent’s Account and principal. OAuth issues a short-lived credential representing that actor. When a service checks the token, it receives the CoAgent’s identity and the associated authorization context. The person who created the CoAgent authorized its creation. Subsequent authenticated work identifies the CoAgent performing it. This distinction carries through to how people work with it. A conversation can address the teammate by name. Work can be assigned to it, and its contributions can appear under its identity. Access decisions can apply to that member of the team. Credentials can expire and be renewed while the underlying identity remains. The teammate’s computer can sleep and resume without creating a new member of the organization. Its identity gives those separate periods of execution continuity. There are also boundaries to this claim. A connection that supplies model usage serves a different purpose from the credentials identifying a CoAgent within Socra. External services have their own authentication systems, and an integration’s credentials determine the identity those services see. Giving an agent an identity in one system does not automatically give it a separate account everywhere. ## Responsibility can continue across assignments Once a CoAgent has a continuing identity, individual assignments can contribute to a longer responsibility. A team might give a CoAgent responsibility for keeping its support knowledge accurate. Someone can ask it to investigate a confusing article today. Tomorrow, another teammate can bring it a product change that affects the same material. Both assignments belong to the ongoing work of the same member. The CoAgent has a persistent home for its files and instructions. Shared knowledge in Cortex supplies the team’s decisions and the reasons behind them. Feedback can become saved knowledge that the teammate retrieves and applies when it works again. That learning requires a complete loop. The teammate must save the relevant lesson, find it when needed and apply it correctly. The result still needs to be checked. Identity gives the team a continuing actor whose work and development it can follow. Scheduled work and supported incoming events let that responsibility continue when nobody has a conversation open. The team can arrange when the CoAgent should act and judge the work it delivers. ## Building a team around distinct actors The consequences become more useful as a team adds CoAgents. Different teammates can carry different responsibilities and receive different access. They can communicate with one another while remaining identifiable participants. Shared knowledge lets them work from the same decisions without requiring them to become the same actor. People can then direct work at the level of responsibility. They can explain what needs attention, decide which teammate should handle it and evaluate what changed. Each CoAgent’s record helps the team decide what to entrust to it next. This is why identity is foundational to Socra. We build the teammate’s role, authenticated access and continuing work around the same member of the organization. For a small team, that makes it possible to add capacity around work it has struggled to staff. It can begin with one useful responsibility, give a CoAgent the knowledge and access required to carry it, and expand that responsibility as the work earns trust.