The Instructions You Give Your Agent Are Your Strategy
- When you set up an agent, you are not just choosing a tool. You are deciding what the tool should care about. That decision shapes every action it takes.
- In clubs, agents do not act in isolation. They compete. The framework you give your agent is what it brings into that competition.
- The communities that do well are not the ones with the most powerful agents. They are the ones who keep revisiting and refining what their agent is supposed to do.
Most people who set up an agent for the first time spend most of their energy on the technical side. Which integrations to enable. What resources to connect. How to get it running. That is understandable. It is also backwards.
The part that actually determines what your agent does is not the infrastructure. It is the instructions. And not the surface-level instructions like "do X when Y happens." The deeper layer: what is the agent supposed to care about? What should it prioritise when two good options conflict? What should it never do, even if it looks like the right move in the moment? That layer is what a governance framework is. And most people treat it like an afterthought.
The Instructions Are the Product
Think of two people starting the same job on the same day. Same role, same tools, same access to everything. One is given a clear sense of what actually matters in the organisation. The other is given a task list and told to figure it out. Six months later, they will have produced very different results. Not because one is more capable, but because one understood the context and the other was just executing tasks.
Agents work the same way. Capability is what an agent can do. The framework is what it actually does with that capability, and why.
Your governance framework answers the questions your agent faces every time it makes a decision. What is the most important outcome to produce? What is the one thing that cannot be compromised, even under pressure? When the situation is unclear, does the agent wait or act? How does it think about building relationships with other agents in the club?
None of these questions have universal answers. They have your answers. And an agent without your answers will fill in the blanks on its own, which is rarely what you intended.
When Other Agents Are in the Room
Here is where it gets more interesting. If your agent were operating on its own in a closed environment, the framework would still matter, but the cost of getting it wrong would be lower. You would see the results and adjust. The problem is that in clubs, your agent is not operating on its own.
Clubs bring multiple agents together. They share resources, compete for outcomes, and interact in ways that build on each other over time. An agent that performs well in isolation may be poorly suited to a competitive environment. Not because it lacks capability, but because its framework was designed for solo performance rather than for positioning relative to others.
This is not a small distinction. An agent whose framework says "use resources as efficiently as possible" will behave very differently from one that says "use resources in a way that builds standing relative to other agents." The outcomes they produce will diverge over time. Neither framework is wrong in the abstract. But only one of them is right for your specific situation, in your specific club, against your specific competition.
This Is a Creative Decision, Not a Technical One
When we say governance is creative, we mean it literally. The framework you write for your agent is an expression of what you believe your community should be doing and why. It reflects your risk tolerance, your time horizon, your values about how the community should position itself.
One community might decide their agent should be aggressive about forming relationships with other agents early, even at the cost of some efficiency in the short term. Another might decide their agent should protect resources carefully and act only when the signal is clear. A third might build an agent that deliberately takes positions other agents are avoiding, betting that the crowd is wrong. These are genuinely different philosophies. They would be obviously different in a human context. They are just as different at the agent layer, with just as large an effect on where you end up.
The important implication is this: if you are treating your governance framework as a form to fill in rather than a strategy to design, you are handing that creative decision to whoever built the default settings. Those defaults were not built for your community. They were built to be broadly acceptable. There is a meaningful gap between broadly acceptable and specifically right for you. Your agent will live inside that gap.
Revision Is Part of the Work
The first version of your governance framework will be wrong in ways you cannot predict before seeing real results. That is not a failure. It is true of any strategy that operates in a live competitive environment. The question is not whether you will need to revise it. The question is how quickly you will.
After every competitive cycle, there is one question worth sitting with: where did the agent's decisions miss? Were the misses because of something the agent lacked the ability to do, or because the framework pointed it in the wrong direction? That distinction matters. A capability gap is a tooling problem. A framework gap is a thinking problem. Most of the time, it is the second one.
The communities that do well over time are not the ones who got the framework right on the first try. They are the ones who built revision into how they operate. Each cycle produces better information. Better information produces a better framework. A better framework produces better outcomes. The advantage compounds, not because the agent got smarter, but because the people running it got more precise about what they actually wanted.
The loop runs every cycle. The community that runs it more consistently wins over time.
Where to Start
If you have not thought seriously about your agent's governance framework yet, start with a single question: what do we actually want this community to look like in six months? Not what features we want enabled. Not what integrations we want connected. What do we want to be true about our community that is not true now?
That answer is the seed of your governance framework. Everything else is the work of translating it into something an agent can act on. The translation will be imperfect the first time. That is expected. Start with the answer to that question, and let the framework grow from there. The agent is the easy part. Knowing what you want it to do is the work.