There is a quiet shift happening in how work gets done.
For a long time, most people interacted with software as operators. We opened the tool, completed the task, updated the record, wrote the note, sent the message, and moved on to the next thing in the queue. The shape of the work was mostly given to us.
AI tools change that relationship. Tools like Codex do not just help us write faster or summarize better. They invite us to describe a desired outcome, break it into parts, inspect the system around it, and build a path from intention to execution.
That is architecture.
Not architecture in the grand, ivory-tower sense. Architecture as an everyday practice: deciding what should happen automatically, what still needs judgment, where context should live, how handoffs should work, and how a system should recover when it gets something wrong.
Agents are not one thing
When people talk about AI agents, it can sound like there is a single destination: build an agent, let it work, watch the magic happen.
The more useful view is that agentic work exists on a spectrum.
At one end, there are small helpers. A prompt that turns rough notes into a clean customer update. A script that checks whether a page has the right metadata. A workflow that drafts a response but waits for a human to approve it.
Further along, there are coordinated systems. An agent that reads a question, retrieves relevant knowledge, checks customer context, proposes a next step, and hands off to a person when the confidence or policy boundary is not right.
Further still, there are networks of agents and tools: systems that plan, act, verify, escalate, and learn from the results.
The important question is not “can we automate this?” It is “what shape of automation is responsible here?”
The CSM version of architecture
For pooled CSM teams, this matters a lot.
Pooled work depends on shared context. It depends on repeatable signals. It depends on the team being able to recognize patterns without flattening every customer into the same journey.
That means the modern CSM is increasingly designing systems around the work:
- What should a customer be able to self-resolve?
- What context should follow a conversation?
- Which signals should trigger a human review?
- Which repeated questions should become knowledge?
- Which workflows deserve automation, and which ones deserve a better human ritual?
Those are not just operational questions. They are architectural questions.
The work moves upstream
The promise of AI is not that everyone stops doing work. It is that more work moves upstream.
Instead of only answering the question, we ask why the question keeps appearing. Instead of only writing the reply, we improve the knowledge that generated it. Instead of only handling the escalation, we inspect the path that failed before it escalated.
AI tools make it easier to build these loops. They also make it easier to build bad loops quickly.
That is why taste, judgment, and systems thinking matter more, not less.
A new kind of literacy
Being good with AI will not only mean knowing the right prompts.
It will mean understanding architecture at the level of everyday work:
- inputs and outputs
- context and memory
- permissions and boundaries
- confidence and escalation
- automation and human review
- measurement and feedback
For a CSM, that literacy is powerful. It turns repeated friction into a design problem. It turns scattered customer signals into a learning system. It turns a pool from a coverage model into a resolution engine.
We are all architects now because the tools have moved closer to the structure of the work.
The question is whether we will design that structure on purpose.