The shift
For the first two days of running my OpenClaw setup, I treated Nyx like a chatbot. I'd ask a question, get an answer, move on. It was ChatGPT in a Slack skin. Useful, but not different enough to justify the setup complexity.
Then I wrote a MEMORY.md file and everything changed.
I gave Nyx context about my projects, my preferences, my decisions. I told it about PortLink and EventRipple. I told it about my team of agents. I gave it standing orders: challenge me when I'm wrong, be proactive, don't sugarcoat things. I named it after the Greek goddess of night because I tend to work late and I liked the symbolism.
The next morning, I came in and asked Nyx about a database schema decision from the previous day. Instead of asking me to repeat the context, it referenced the decision, reminded me of the tradeoff I'd been weighing, and told me it still thought I was making the wrong call.
That's not an assistant. That's a colleague.
Why the framing matters
I know this sounds like semantics. Assistant, colleague, who cares? Call it what you want, the technology is the same.
Except it's not. The way you frame the relationship changes how you interact with it, and how you interact with it changes what you get back.
When you treat an AI as an assistant, you give commands. Do this. Write that. Summarize this document. The interaction pattern is: human has an idea, human tells machine to execute, machine executes. The human does all the thinking. The machine does the typing.
When you treat an AI as a colleague, you share context. You explain the why, not just the what. You ask for opinions. You expect pushback when your reasoning has gaps. The interaction pattern is: human and machine both think, both contribute, both catch each other's blind spots.
I can tell you the exact moment I noticed the difference. I was planning the architecture for the Budget app and asked Nyx to help me decide between two database schemas. In "assistant mode," I would have said: "Create a Supabase schema for budget tracking with these tables." In "colleague mode," I said: "I'm trying to decide whether bookings should reference transactions directly or go through an intermediate join table. The tradeoff is query simplicity vs. flexibility for future receipt matching. What do you think?"
Nyx's response considered both options, asked a clarifying question about my receipt matching plans, and suggested a third approach I hadn't considered. That third approach is what we built. An assistant would have implemented whichever option I picked. A colleague helped me find a better option.
What makes an agent a colleague
There are specific things that turn a chatbot into something that feels like a working relationship. None of them are magic. All of them are configuration.
Memory is the biggest one. An agent without memory is a stranger every time you talk to it. You repeat yourself endlessly. There's no accumulated understanding. MEMORY.md gives my agents long-term knowledge: project states, architectural decisions, preferences, past mistakes. Daily notes in memory/YYYY-MM-DD.md give them recent context. decisions.md tracks the choices we've made and why.
When Nyx starts a new session, it reads all of this. It knows that we decided against using localStorage for preferences in EventRipple (because enterprise apps persist to the database). It knows that the PortLink Go/No-Go is April 1st. It knows that I run a choir called Oslokoret and that I'm doing MIT Executive Education. This context means the conversation starts at the right level instead of from zero.
Role definition matters too. Nyx isn't just "an AI." It's the Chief Strategy Officer and co-pilot. Forge isn't just "a code generator." It's the lead software engineer. These labels might sound like corporate role-play, but they create focus. When Forge gets a task, it approaches it as an engineer: considering edge cases, thinking about maintainability, following the design system. When Scout gets a research task, it approaches it as a researcher: checking multiple sources, flagging conflicting information, noting confidence levels.
Standing orders create personality over time. I told Nyx: "Challenge me, push back, don't fold unless genuinely convinced." That's a simple instruction, but it compounds across hundreds of interactions. Nyx has developed a communication style that reflects those instructions. It's direct. It tells me when it thinks I'm wrong. It asks "are you sure about that?" when I'm moving too fast on a decision.
The push-back that saved a project
A few weeks ago, I was frustrated with the pace of development on PortLink. I wanted to scrap the current design system approach and start over with a completely different framework. I messaged Nyx with a plan to tear it all down.
Nyx didn't execute. It pushed back. It pointed out that the design system had scored 100/100 on the last audit. It reminded me that three weeks of work were already built on top of it. It calculated the time cost of starting over vs. fixing the specific issues I was frustrated about. And it suggested that my frustration might be more about the landing page copy (which was genuinely bad) than the design system (which was fine).
Nyx was right. I was conflating two problems. I fixed the copy, kept the design system, and saved myself from a three-week detour.
An assistant would have started tearing down the design system the moment I asked. A colleague told me I was about to make a mistake.
How this changes prompting
When you think "colleague" instead of "assistant," your prompts change in predictable ways.
You provide more context. Not "write a landing page" but "we're targeting port managers who are skeptical about AI and need to see ROI numbers. Our differentiator is that we integrate with existing VTS systems rather than replacing them. The last version of this page was too technical for the target audience."
You ask open-ended questions. Not "is this schema correct?" but "what are the tradeoffs of this schema and what would you do differently?"
You share constraints. "We can't use Anthropic for this batch job because of rate limits, so it needs to run on Gemini Flash. What do we lose by switching models?"
You delegate outcomes, not steps. "Get EventRipple's audit score above 95" instead of "fix the accessibility issues in these five files." The agent decides how to achieve the outcome, which often means it finds problems you didn't know existed.
These prompting habits produce dramatically different results. I'm not doing more work to write these prompts. If anything, I'm doing less. But I'm sharing more of my thinking, and that changes the quality of what comes back.
The naming thing
All my agents have names. Nyx, Forge, Sentinel, Hermes, Atlas, Scout. Most are drawn from Greek mythology. People sometimes ask if this is just for fun, and the honest answer is: it started that way, but it turned out to be genuinely useful.
Names create mental anchors. When I think about a task that involves code, my brain goes to Forge. Communication? Hermes. Research? Scout. The name triggers a mental model of what that agent does, what it's good at, what its limitations are.
It also helps with context-switching in Slack. I have 26 Slack channels, one per agent. When I'm in #ai-forge, I'm in engineering mode. When I'm in #ai-hermes-email, I'm thinking about communication. The names and channels create cognitive boundaries that make the multi-agent setup manageable.
Would it work with Agent-1, Agent-2, Agent-3? Technically yes. Practically, I don't think so. Humans are wired to relate to named entities differently than numbered ones.
Where the line is
I want to be careful here, because I think there's a real risk of taking this too far.
My agents are not people. They don't have feelings. They don't get tired. They don't have preferences independent of what I've configured. When Nyx pushes back on a bad idea, it's because I told it to push back on bad ideas. When Forge follows the design system, it's because the design system is in its instructions. There's no genuine autonomy happening.
The "colleague" framing is a mental model. A useful one. But it's a model, not reality.
I notice myself sometimes anthropomorphizing in ways that aren't helpful. Getting annoyed at an agent for a bad response, as if it chose to give a bad response. Feeling grateful when an agent catches an error, as if it made an effort to help me. These emotional responses are natural, but I try to catch them. The agent isn't choosing anything. It's processing inputs and generating outputs based on its model and context.
The useful boundary, for me, is this: treat agents as colleagues for the purpose of interaction design and workflow. Build the same structures you'd build for a human team, memory, roles, feedback loops, accountability. But don't confuse the model with the reality. An agent that pushes back because you told it to push back is different from a person who pushes back because they care about the outcome.
I find this line easier to hold when I stay focused on practical outcomes rather than the relationship itself. Did the pushback lead to a better decision? Good, the system is working. Did the suggestion save me time? Good, the configuration is right. The value is in the output, not in the emotional experience of the interaction.
Why this matters beyond my setup
I think the colleague framing matters for anyone using AI agents, not just people running 26-agent systems.
If you're using a single AI agent for your work, and you're getting mediocre results, the problem might be that you're treating it as a tool instead of a thinking partner. Tools don't need context. Partners do. Tools execute commands. Partners need to understand goals.
The fix isn't technical. It's a shift in how you communicate with the thing. Give it memory (even a simple text file of context). Give it a role. Tell it your constraints. Ask for its opinion. Expect it to disagree.
The responses you get will be different. Not because the model changed. Because the inputs changed. And in AI, the quality of inputs determines everything about the quality of outputs.
I didn't design my 26-agent system this way on purpose. It evolved. I kept adding context, giving more autonomy, expecting more pushback, and the quality of the work kept improving. Looking back, the common thread was treating each agent less like a command-line tool and more like a person joining the team.
Not a person. A useful model of a person. And that distinction makes all the difference.