Tag: Skills

We the People

A company’s Backbone skill, the single document every human and AI agent reads from, is really its constitution. And the most important thing a constitution contains is the rules for changing itself.

We’ve been thinking about what a company’s constitution would look like.

It started as a practical problem. At Activate Intelligence we’ve been building what we call the Backbone skill, the single document that tells every one of our AI agents who we are, what we believe, how we work and how we make decisions. Everyone gets a version of it. You can talk to it, ask it questions, argue with it. It’s the base layer that everything else sits on.

The thing is, once you have a document like that, you notice it’s not really a manual for the AI. It’s the founding document of the whole organisation. The same text that tells an agent how we make decisions is the text that tells a new colleague the same thing. It’s what everyone, person or machine, checks against before they act. So on a call this week I said it out loud: the Backbone skill is basically a constitution.

And a constitution isn’t a mission statement. A mission statement is a poster in the lobby. A constitution is the thing every agent, human and AI, reads from before they act. Same base layer for all of them. When a person and a machine disagree about what the company would do, they’re not appealing to their own guesses, they’re appealing to the same text.

Part of why this suddenly matters is the AI. A purely human organisation can run on principles that are never written down. People pick them up by imitation, by watching what gets praised and what gets quietly ignored, by osmosis in the corridor. It works, sort of, with all the limits you’d expect: the rules are fuzzy, they drift, and nobody quite agrees what they are. An AI agent doesn’t have that luxury. It has no corridor to hang around in. If you don’t give it clear context, it doesn’t improvise its way to your culture, it just fails, or worse, it confidently does the wrong thing. The moment you put agents to work, the unwritten rules have to be written. That’s uncomfortable, and it’s also useful, because it forces you to actually decide what you believe.

Here’s the part we keep coming back to. The most important thing a constitution contains is the rules for changing itself.

That sounds like a technicality and it’s actually the whole point. If the founding document is fixed, it rots. If anyone can edit it at any time, it means nothing. What you want is a document that says, in writing, how it can be amended, by whom, through what process. Adding something, removing something, changing something, each has a defined path. Once that mechanism exists, the document can stay alive without falling apart, and you don’t need a founder standing over it forever.

We are all the founding fathers and mothers. That’s roughly how I put it. Nobody owns the constitution, everybody signs it, and the signature that matters is agreeing to the process for changing it. After that, every agent in the company, whether it runs on coffee or on tokens, works from the same base and improves it the same way.

We like this framing for a boring reason: it’s easy to explain. I used almost exactly the same words in a client pitch the morning before, and it landed immediately. People already know what a constitution is. They know it’s meant to outlast the people who wrote it. They know amendments are a normal, healthy thing and not a crisis. You don’t have to teach any of that.

It also connects to something we’ve been circling for a while. We keep talking about the Backbone skill as the “why”, the base layer, with a data layer underneath it and a fast, messy layer of experiments on top. The experiments come and go. The data changes every day. The constitution is the slow layer, the part that’s supposed to change carefully and rarely, and to say clearly how it changes when it does.

What makes this feel bigger than us is that it isn’t really about Activate, or about any one company. It’s a general shape. Any organisation that’s going to have humans and AI agents working side by side needs a single, self-amending founding document they all read from. The companies we’re doing this with are just instances of it. The idea is the interesting thing, not the logos attached to it.

This isn’t finished thinking. We’re not sure yet how thick a constitution should be, or how you stop the amendment process from becoming its own kind of bureaucracy. But we’re fairly convinced the shape is right: one base layer, shared by people and machines, that contains the rules for changing itself.

More on this as we actually build it.

A Rash Conclusion

Everyone worries about AI replacing doctors. After 24 hours in the hands of the NHS, I think they’re looking in the wrong direction.

GP, A&E, then other parts of the hospital. Every shift, a new doctor. Every new doctor, the same questions. The same story, retold from the top. Every single one of them then took a picture of my rash with their phone.

The first GP I saw actually had an AI assistant. It recorded our conversation and drafted a letter, which he printed on that grey recyclable paper the NHS uses for everything and which absolutely no one in the chain that followed ever read.

Meanwhile, I had Claude in my pocket. It knew my whole story from the first symptom. It could interpret the blood results before the doctor did, and flag a couple of things worth asking about. By the third doctor, I was essentially a transcription layer between Claude and the NHS.

My whole situation could have easily be baked into a Claude skill, easy to interpret by any LLM based diagnostic software.

I’m not going to argue AI should replace doctors. Mine were careful, kind, and correct. But AI replacing the patient? That part is ready now. The doctors get a well-organised history, an accurate timeline, current medications, no retelling. The patient gets to rest.

The hard part in medicine is context. The context of the whole field is enormous and probably beyond what current AI can carry reliably. But the context of one specific patient, with one specific problem, unfolding over a few days? That’s hard, but achievable with today’s tech. Mine was, all things considered, a relatively simple case. Cases at this level of complexity still make up the bulk of what the system handles every day.

Which brings me to the bigger point. The waste I watched from the inside over 24 hours was remarkable: the same story told six times, the same photo taken six times, the same pieces of information gathered again and again because no one had time to read what the previous shift had written. If we can shift even part of that burden onto the patient’s side, with the patient’s own AI carrying their story cleanly from one clinician to the next, it starts to look like a real contribution to the sustainability problem that every public health system is wrestling with.

And once we have that down, the Doc AI will get much better too.

Not today. Tomorrow for sure.

Playing with Claude skills

Using skills we can capture *why* software components are built, not just the *how*, giving developers better context when working with unfamiliar code. This isn’t about replacing developers, it’s about empowering them. We’re now exploring ways to capture skills from conversations, documents, and the natural flow of work.

For the last couple of weeks I have been playing with Claude skills.

It’s a cool way to package knowledge on how to do stuff in a prompt which can be retrieved any time your agent needs it. They work with Claude, but you can easily integrate them in any LLM-based process.

My first experiment was building a skill about our company. Read the website, read some internal documents, read technical documentation, distil a context that can be used any time I’m writing or thinking about business stuff. But the most interesting aspect is that everybody on our team can now use the same context for whatever work they are doing.

The next experiment was to build a skill to create Spritz agents (there’s a very good skill-building skill on Claude, which helps a lot with the building and packaging of skills). I showed Claude the blueprint for agents that we use every day, then showed some fully developed agents.

Then I tried to build a simple “hello world” agent from scratch with this prompt:

Build a Hello World Spritz agent. It should ask for the user name, then use the Anthropic API to generate a greeting. Deploy the agent on AWS using the CLI and test it. Ask me for an API key when you are ready.

I was able to obtain a working agent in about 10 minutes, but it took a few nudges here and there where the skill didn’t cover details.

At the end of this process I prompted:

Based on the experience of this job, update the skill file so next time we will be able to complete the task without obstacles. Do not include in the skill any specific information about this agent or my development context.

The second time it worked end to end.

I have since tried to build a bunch of different agents, always adding more details and nuances to the skills.

This is not (just) about production

Of course this is not about replacing developers, it’s about empowering them. The agents I build will not be used in a production environment; they are mostly proof of concept.

Using skills (or some similar prompting technique) we can capture why various software components are built, not just the how, allowing developers to have a much better context when they need to interact with code they have not created, or even when they go back to a project after a while.

They are an amazing teaching tool to explain to others how things work.

For now we have simply started a GitHub repository with the skills we have built so far. It’s easy to ask Claude, ChatGPT or any other tool to find and retrieve skills from the repo and use them. Now we are figuring out new ways to capture skills from the flow of work we do, from conversations we have, from documents we create.

Yet another step towards an interesting future.