Agent roles and team structure

A few months back Anthropic released Agent Skills. Which is an open standard for providing instructions, patterns and workflows to AI agents. Or as how Anthropic states it: “Building a skill for an agent is like putting together an onboarding guide for a new hire”. Considering what our goal is, this is perfect. Exactly what we need. Procedural workflow instructions for agents. Limiting context usage only to the needed skill and on the required depth. Thus making the journey towards our goal for Service as Software, that much easier. I’m excited!

Agent Skills enables us to:

1. To improve our context usage
2. To simplify the separation of business logic and tool usage
3. To simplify our organizational structure

First two: improved context usage and separation of business logic are really important, but not our “main dish” for today. The topic I want us to consentrate on today is point three: how skills could simplify our organizational structure. But first, lets get the initial two out of our system:

First one, reserving context use is a big thing on its own, as it can prevent “context rot”. Where agents ability to pay attention to critical parts of the data deteriorates as the context grows. Important functinality on the technical level. Second one, is actually quite exciting from an automation point of view. Agent Skills enable a more structured separation of business logic (workflows, instructions) from the tools use (code, scripts, integrations). Which is a key point when automating business processes. Separation enables better read- and maintainability. Both points are important and would be worthy of their own posts/chapters. But today, we consentrate on point number three. Before we dive in, let’s add some background:

Business implications

Agent Skills are reusable, scalable and contain business knowledge. Defining a way for us to structure our business knowledge and leverage it through agents. This ofcourse has major business implications and should spark the interest of any business executive out there. One could have version controlled organizational knowledge which enables cost effective automation across business operations. Add and scale skills as necessary. And this is only on the “skills level”.

Now we separate from the actual Agent Skills standard to the consept of a skill. With skills we can enable single agents to handle several workflows and tasks. An agent would call upon a spesific skill only when necessary. As in, one agent could have multiple skills. Thus we can start looking at agents from more of a role perspective. Where each agent/role has a set of skills at their disposal. Similar to the way we have been structuring human organizations.

Current technical maturity

Even though I mentioned earlier that Agent Skills help simplify our organizational structure, I was referring to the underlying concept of skills they introduce. This concept of skills will enable us to simplify our agentic organization. The current example skills the actual standard introduces are still quite granular. And there are no skill combinations that would make up a role as we described it. I want to clearly distinguish the current technical capability from the consept of skills. Actual agent roles as we describe are still to come. We are now simply discussing how skills could be applied in the future.

Let’s assume that soon we will have well spesified roles accompanied by necessary skills. A role as in a set of skill run by a spesific agent containing the necessary tools. Tools and MCPs as still in the mix as before. Skills provide the instructions on “what to do”. Tools provide actions that agents can perform/invoke. So the agent could follow the instructions provided by the skill and invoke the tools/actions it deems necessary to achieve its goals. Skills could be seen as an instructions layer where the tools are an action layer. Next step would be to tie these roles to processes. A role, could be the combination of tools, skills and process.

Aiming for Service as Software

As we are building an IT service in a “Service as Software” fashion. We will need a set of roles to run and handle the majority of the work. Previously one would have been careful not to give too many tasks as in responsibilities to a single agent. But now that we approach agents more from a role perspective. The game has changed and we can simplify the organizational structure that we need to run our IT service. Making it far easier for us to follow industry best practices on structuring for IT services. Kind of like this:

We would define the structure and processes necessary to deliver our service. Then organize the roles around it. Our IT service would follow the basic structures for project and service organizations. Then we’d add the related roles and their relation on process level. As we know, processes contain clear interaction points for different roles. After this mapping one would “only” need to add the necessary skills to the identified roles. And configure the skills with the correct tools that can interact with our underlying business applications. Needless to say, our skills would need to contain the necessary business logic as in the workflows and explicit knowledge needed to perform the service we are providing.

An example operational service role with a set of skills to manage service desk tasks:

On a conseptual level, this almost feels too simple. We already have all the necessary information. Most of this is general knowledge at this level. But I bet we will find a lot of complexity and trouble when diving any deeper. The sheer scale of defining and configuring such a organization will be huge. Not to forget about the AI limitations we still have. Things are moving fast, limitations are being tackled one after the other. I’ve already noticed that there are many IT suppliers offering “AI supported” service desk solutions.

I hope we could do this more. Diving into this will be fun. And this is what we are good at!

As a final touch, our organizational structure could start looking like this:

Where our “Model T” (name of our IT Service) would be “agent based” on the operational level. And we still have humans in the mix.

Closing for today with a question to anyone sharing our journey:

What next? We have many interesting directions to discuss:

1. I want to talk about how traditional roles will change due to this. How will this impact leadership? Could organizations reduce their IT experience or does it go the other way round? Will IT expertize be even more important, as one could run a whole company from their terminal?

2. Will organizational maturity sky rocket when agents actually follow processes to the letter? One wouldn’t need to wait for CAB meeting next week to get all persons into the same meeting. Agents could run CAB approvals asyncronously by sending tasks to necessary approval roles. CAB approvals would be ready in minutes. Standard changes would actually be logged when performed. Is this a dream come true for the process people?

3. Lets continue more on the details level. How to apply IAM accesses, make schemas, limit skill usage. How to ensure agents/roles “stay in their responsibility area”: The “Technical Service Ops” agent assigned to “Run” phase could easily generate new code to be built and installed within an incident, but it would bypass the process and miss the necessary approval gate. This actually might be two different post.

Different interesting directions to discuss. Which direction would you want us to take next? I’m a bit leaning to the first one, but the third one would be good for our learning. Have a say, you can contact me in Linkedin.

Hope this made you think. Until next time. Thank you.