What are you automating?

When I got to Within, Emmanuel, my boss, and I were talking about the goals and metrics he'd committed to our board. Several were tied to project execution, so I asked him to show me how we were managing projects. He opened a project plan on a customer-facing site, with our tasks and the customer's sitting together. Then he opened another page to show me the next project. Then another.

To see where a project was in its lifecycle, he'd open each customer's project page and update it, usually doing it himself. There wasn't a project rollup into a higher-level view. We both knew this process wasn't going to scale to meet the demand we knew was growing, and fast.

The team was already using the Within AI agents to define the shape of value delivery work, which was a huge accelerator. Instead of spending a couple of months doing discovery of our processes, we had what felt like a treasure map.

In the last article I mentioned the 138 variants we found in work we thought was standard. That became the starting point for a catalog, and against the catalog, more than fifty automation opportunities.

The instinct to automate

During kickoff meetings, I'll ask customers what their goals are. 90% of the time, the answer is to map their current processes. When I ask why they want to map their business processes, they almost always say, “So we can automate our work.”

I get it. For years I gave that same default answer. My decks had “Automation” plastered across the pages, promising massive benefits, rarely talking about the work needed before you get to the automation. I'd present plans to save millions by simply automating, wallpapering over years of process debt with not much more than a series of “if statements.”

Understanding the work gives you a choice: stop it, automate it, or redesign how it gets done. For our team, the work after customer meetings was a place where automation could give us relief and lay the first Lego brick.

After the meeting

The team was already using AI-assisted meeting notes to update our CRM and project management tool by hand. The note-taking tool gave us generic action items that didn't account for the types of meetings we ran with our customers or capture the information that was actually important to us. Filling in the gaps, remembering what happened, and piecing together AI-generated notes with their handwritten notes took focused time. A majority of those tasks didn't take much judgment, but remembering to fill in the new CRM field because we were tracking something new that week still took mental bandwidth. I wanted our delivery leads spending that attention on work that actually added value for the customer.

Part of the job was asking people to update the systems. Then asking again, and again. Sometimes we'd update our CRM live during a team meeting, but almost never the project management tool at the same time, so our tools fell out of sync. Our entire team would sit there watching Emmanuel update the tools live as the team gave him a verbal update.

So we started by having the agent read the transcript and the delivery lead's calendar to figure out the meeting type. The meeting types were already standardized across our delivery motions, so the classification told us where a project stood in its activation journey. With that context, the agent could propose an update in the CRM for a person to approve.

Knowing the meeting type meant knowing which tasks from the catalog belonged to each specific milestone. The agent could pull out action items, compare them with open tasks in our project management tool for that milestone, and propose what to close or add for our delivery lead to approve.

Our automations were intentional, based on the initial opportunity signals. Even more opportunities unlocked as the other Lego blocks clicked into place, every brick another in the foundation of how our team works.

Where the human sits

The delivery lead is responsible for the work. They don't have to work out every action themselves anymore, but they do have to decide if the actions the agent wants to perform are aligned with the human's goal. That judgment stays with the person, and so does responsibility for the result. This doesn't mean interpreting code, but it does mean owning outcomes.

The delivery lead approves work before anything critical or irreversible happens. In our CRM, the agent inherits their permissions, so it can't touch anything they couldn't already touch.

Making it stick

Not everyone used the agents after their meetings. When somebody moved their objects in our CRM by hand, the fields the agent knew to fill out stayed empty. They'd show up to a team meeting with an incomplete picture, and we'd ask questions people thought they had already answered and end up making incorrect assumptions from the wrong data.

We didn't apply a mandate to fix the problem, but everyone was strongly encouraged to lean in. What helped was building agents at the right points in our work so they could deliver a complete package of work. People watched the agents work for someone else, ran it once, and wanted that same mental relief from an agent handling those low-value, repeatable steps.

The person who used to enter the meeting notes into our CRM manually and groom their project boards now types one line into their AI chat tool and the agent goes to work. They can grab a coffee while the agents prepare the work or switch their focus to something else.

The hours each delivery lead saved went back to customers and personal development. Instead of checking boxes and pushing buttons, we spent time talking about problems we saw across accounts or whiteboarding solutions.

The next article takes up the decisions about how to organize the work itself, including where responsibility sits and how work passes between people, agents, and teams. That's where I'll get into operating contracts between humans and agents.

This is part three of four. Subscribe for access to the rest of the series.