Category: AI Agents

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.

It’s a good time for CEOs

For most of my career I have fought on one side or the other in the eternal battle between unreasonable CEOs and reasonable CTOs. It’s always the same story: CEOs without a big tech background always coming up with ideas, CTOs trying to stem the flow, doing their best to manage expectations and deliver reasonably good products.

While helping bootstrap startups, for the last ten years I have been actively working to come up with a long series of design techniques to throw in the way of ambitious CEOs to slow them down. Yes, yes, good idea, but we need to go through a rigorous design phase, we need to user test, then we need to decide what impact it has, then we put it in an endless queue of kanban boards… you’re never gonna get it.

More recently, as the unreasonable CEO of a new small company, a bit by myself, a lot with a small and clever team of human and AI agents, I have been creating tons of stuff, both for my own company and for many of our clients. At an unprecedented speed. This is not a percentage increase, this is an order of magnitude.

And I have been happily dreaming with other CEOs of ideas, features, whole new products, without having any idea of how to get there but knowing that thanks to today’s magic (and counting on tomorrow’s improvements) we will get there, we will iterate, we will improve… we will figure this out.

It’s a bit like having a parachute that makes jumping off cliffs much safer. You have to believe it works, and I think it’s reasonable that many don’t. I’ve been jumping off these cliffs for a few years now, and yeah, sometimes you get a bruise. But it’s so much more fun.

Now I often find myself on the other side of CTOs. They want predictability. They want detailed plans. They want costs. They still have to deal with the rest of the company which is still moving at the glacial speed of 2025. I’m sure that eventually we’ll all get there, but while for a very long time I have fought on the side of CTOs, now I’m increasingly finding myself having much more fun playing with CEOs.

The most unreasonable, the better.

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.

The magic of AI search

I just built yet another MCP experiment.

First I created a Python script to process .md files: chunk them, create embeddings, store everything in a PostgreSQL database.

Then I built an MCP server which can search the database both using semantic search (embeddings) and more traditional full text search as a fallback mechanism.

I find absolutely fascinating watching Claude interacting with this tool, because it’s not just about converting my request to a query, it’s the reasoning process which happens in order to find what it needs which is brilliant.

Let me show you an example:

Continue reading “The magic of AI search”

More MCP fun: Claude talks with ChatGPT

I started with a new idea this morning: create an MCP server that allows Claude to talk to the various OpenAI models.

Now I can ask Claude to ask any of the openAI models.

What I find more fascinating is how Claude is figuring out how to use these new tools. The key is in the description of the tool, the “manifest” that Claude gets when the server is initialised (and is probably injected at the beginning of every chat).

PS: if you want to try this at home, here’s the recipe.

As an example, here’s how the description of today’s MCP server looks like:

Continue reading “More MCP fun: Claude talks with ChatGPT”

Scraping Challenges and Open Standards

Following up what I posted recently about Scrape wars, I wrote a longer post for my company site. Reposting it here just for reference.

We’ve talked before about how everything you write should work as a prompt. Your content should be explicitly structured, easy for AI agents to read, interpret, and reuse. Yet, despite clear advantages, in practice we’re often stuck using workarounds and hacks to access valuable information.

Right now, many AI agents still rely on scraping websites. Scraping is messy, unreliable, and frankly a bit of a nightmare to maintain. It creates an adversarial relationship with companies who increasingly employ tools like robots.txt files, CAPTCHAs, or IP restrictions to block automated access. On top of that, major AI providers like OpenAI and Google are introducing built-in search capabilities within their ecosystems. While these are helpful, they ultimately risk creating a new layer of dependence. If content can only be efficiently accessed through these proprietary AI engines, we risk locking ourselves into another digital silo controlled by private platforms.

There is a simpler, proven, and immediately available solution: RSS. Providing your content via RSS feeds allows AI agents direct, structured access without complicated scraping. Our agents, for example, are already using structured XML reports from the Italian Parliament to effectively monitor parliamentary sessions. This is an ideal case of structured openness. Agents such as our Parliamentary Reporter Agent and the automated Assembly Report Agent thrive precisely because these datasets are publicly available, clearly structured, and easily machine-readable.

However, the reality isn’t always so positive. Other important legislative and governmental sites impose seemingly arbitrary restrictions. We regularly encounter ministries and other government websites that block access to automated tools or restrict access based on geographic location, even though their content is explicitly intended as public information. These decisions push us back into pointless workarounds or simply cut off access entirely, unacceptable when dealing with public information.

When considering concerns around giving AI models access to content, it’s essential to distinguish two different use cases clearly. One case is scraping or downloading massive amounts of data for training LLM models (this understandably raises concerns around copyright, control, and proper attribution). But another entirely different and increasingly crucial case is allowing AI agents access to content purely to provide immediate, useful services to users. In these scenarios, the AI is acting similarly to a traditional user, simply reading and delivering relevant, timely information rather than training on vast archives.

Building on RSS’s straightforwardness, we can take this concept further with more advanced open standards, such as MCP (Machine Content Protocol). Imagine a self-discovery mechanism similar to RSS feeds, but designed to handle richer, more complex datasets. MCP could offer AI agents direct ways to discover, interpret, and process deeper levels of information effortlessly, without the current challenges of scraping or the risk of vendor lock-in.

Of course, valid concerns exist about data protection and theft at scale (curiously the same concerns appeared back in the early RSS days, and even when the printing press first emerged… yet we survived). But if our primary goal is genuinely to share ideas and foster transparency, deliberately restricting access to information contradicts our intentions. Public information should remain public, open, and machine-readable.

Let’s avoid creating unnecessary barriers or new digital silos. Instead, let’s embrace standards like RSS and MCP, making sure AI agents are our partners, not adversaries, in building a more transparent and connected digital landscape.