Blog
A year ago I thought we were going to automate a few processes with AI. Pick a workflow that was painful, drop in an agent, save somebody’s time, move on to the next one. Week after week until the backlog was done.
Six months and five shipped systems later, I don’t think that’s what we’ve been doing at all. We’ve been restructuring how the company operates so that AI can participate in it. Those aren’t the same project, and the difference matters more than anything else I could tell you in this post.
The frame we started with was wrong
The process-automation frame assumes the process stays the same and you just add a new worker. The CSM used to review accounts on Monday morning. Now a nightly job does the review and hands them a prioritized list. Same process, new participant, productivity goes up. That story holds for the first project or two.
It falls apart around project three, because by then you notice that every agent is asking the company to answer questions nobody has ever had to answer out loud. Which system owns this fact? When the CRM says the ARR is one number and the billing database says another, which one is right? What is the canonical name of this account? Who decides?
No human employee ever needed answers to these questions. Humans ask around. They know that the sales ops person is the authority on deal amounts, that engineering’s telemetry uses a different account name than the CRM does, that the billing discrepancy is a known issue nobody ever formally resolved. Institutional knowledge fills the gaps. An agent has no institutional knowledge. It reads what’s written down.
The first time we ran into this, we treated it as a bug. By the fifth time, I realized it was the whole job.
Agents are new participants, not new tools
An agent is the first actor in your company that can’t ask around. It can’t DM the sales ops person for a clarification. It can’t learn from three months of watching how the team actually operates. It takes what the company has written down, follows the rules it’s been given, and produces an output.
That means the company has to write things down, in the form the agent consumes. Not a wiki that nobody updates. A database schema, an identifier mapping, a documented source of truth, an ontology of what “customer” and “deal” and “ticket” mean and how they relate to each other.
This is an organizational change, not a technical one. The technical part is easy once the decisions are made. The hard part is the decisions. Who owns the canonical definition of an account? When the sales team and the CS team say “the customer,” are they referring to the same legal entity or two different ones? What happens when the product telemetry says the customer is active but the CRM says the contract ended last month?
These questions have answers. They’ve always had answers. They just lived in people’s heads, and different people had different ones. An agent forces the company to pick one answer and make it the company’s answer.
What we actually built
When I look back at the CS Copilot project, the artifact I’m most proud of isn’t the scoring model or the dashboard. It’s a document t that tells us which how to map a customer accross multiple systems that we have.
That document doesn’t sound like a big deal. But building it required the sales team, the CS team, and the engineering team to agree on what an account is, which naming convention wins when two systems disagree, and who gets to make the call for new accounts going forward. It required us to decide, for the first time as a company, that there is one canonical list of customers and everything else resolves to it.
The scoring model is 500 lines of code. It was two days of work. The customer mapping document and the operational decisions around it were a couple of weeks, and they’re what made everything else possible.
The Plumbing Is the Operating Model
When we started the coaching pipeline, I expected to rebuild most of the data layer from scratch. Different data sources, different agent, different output. It turned out the pipeline reused the alias table wholesale. Every rep in the coaching system is mapped to the accounts they own through the same canonical identifier structure that health scoring uses. Other AI agents now use it too.
This is what I mean when I say the real work is organizational. What we’re building under the agents is a schema for how the company describes itself. An ontology, in the old-fashioned sense. A canonical list of entities, their identifiers, their sources of truth, and the rules by which they relate. Every function leader is gradually being pulled into deciding what their function’s data needs to look like for an agent to consume it.
None of this is what I thought we were doing when we started. We thought we were shipping AI features. We were actually rewriting the company’s data model one project at a time, and the AI features were the forcing function.
Who has to own this
This can’t be delegated to an “AI team” or an engineering side project. The decisions aren’t technical. They require the person who owns a function to decide what their function’s data is going to look like, which definitions are canonical, and which systems are authoritative for which facts.
Sales has to own the CRM shape. CS has to own the success and health data. Support has to own the ticket taxonomy. Engineering has to own the product telemetry schema. Somebody at the top, whether that’s the CEO, the COO, or the head of operations, has to own the decision that all four align on one set of identifiers and one set of definitions. If no one is empowered to make that call, agents will keep producing subtly wrong answers, because they’ll be reading subtly disagreeing data.
The work pays compounding interest. Every clarification the sales team makes about what an account is makes every future AI project easier. Every identifier that gets canonicalized is one fewer place the next agent will trip over. A company that does this work for two years looks, from the outside, indistinguishable from one that hasn’t, right up until you try to build an agent inside each and realize one of them is impossible and the other is a weekend.
The takeaway
If you’re still thinking “which process do we automate first,” you’re in the wrong frame. The real question is what your company needs to look like so agents can participate in it. Process automation is a side effect of answering that question well, and a source of constant frustration when you try to skip it.
The starting point isn’t picking a workflow. It’s naming your main business entities, picking a canonical identifier for each one, and documenting which system is the authority for each kind of fact. It’s unglamorous. It doesn’t demo well. It’s also the thing that separates companies where AI is going to work from companies where every project is going to feel like a fight against the company’s own data.
What’s next
Next week we move to marketing. How we automated content research, outline generation, internal linking, and SEO topic scoring for this blog series. Including the honest part, which is that the AI-generated draft is still 70% human edits before it ships. You’re reading a direct product of that pipeline right now.
Stay updated on Birdview's AI Automation Journey
This is Part 5 of “Becoming AI-Native,” a weekly series from the Birdview PSA team on our AI transformation journey. Follow along here on Birdview’s blog, on Vadim’s LinkedIn
