In The Autonomy Spectrum, I argued that most AI agent workflows aren't a choice between LLM-driven exploration and deterministic code execution. They're both, at different steps, and the steps move along that spectrum as a workflow matures. I used a content team assessing briefs and creating Asana tasks as one of the examples, where someone analyzed a series of blog briefs for brand fit and messaging, and then created tasks in Asana for the blog authors and content team. That example was mine, and this is the full story of how it moved.
It started on a Tuesday morning in January, at a local coffee shop, with a problem that had nothing to do with AI and everything to do with a spreadsheet. Every month, the demand generation team hands our content team a batch of blog requests, typically 15 to 20 topics, alongside a spreadsheet with linked blog briefs, each one mapped to a specific search prompt we're trying to win. My job was to turn that spreadsheet into Asana tasks: instantiate the BLOG template, set the publication date, calculate subtask due dates for draft and review, assign the right teammate, and drop a link to the brief into the task description. One blog at a time, in a Claude.ai chat, correcting the day of week when Claude got the math wrong, re-explaining the template structure when an update wiped it out. Three or four tasks and I was done for the day, ready to move on to other tasks. Firmly non-deterministic, in the vocabulary of the spectrum: I was guiding every decision, and no two sessions looked quite the same.
By the eighth session, six weeks later, my instructions had shrunk to three words: “Do the thing.” Claude read the spreadsheet, matched briefs to requested topics, reviewed each brief for competitor citations and weak positioning, created five fully configured Asana tasks with correct dates and working SharePoint links, and reported back. My part was a copy and a paste. Everything after that happened on its own, and most of it had moved to the deterministic end of the spectrum.
The system that automated my content team's production runs on CData Connect AI, the same platform the blogs it produces are about. That's not a coincidence I engineered for this article. It's the reason the workflow could move along the spectrum at all, and it's worth walking through exactly how.
What the workflow actually does today
The current version starts with two inputs: a monthly list of requested topics from demand gen, and a spreadsheet of content briefs sitting in an Excel file on SharePoint. Claude reads that spreadsheet through Connect AI, which exposes Excel Online as a searchable, readable source, and matches the highest-value brief to each requested topic based on how well the brief's prompt target lines up with what's been asked for.
For each match, Claude opens the underlying Word document and reads it with an editorial eye. The briefs linked are strong starting points, but they often cite competitor platforms to illustrate a point, and they don't always push the CData angle as hard as they should. Claude flags those competitor citations, replaces them with third-party sources that make the same argument without naming a competitor, and sharpens the product messaging and call-to-action framing before the brief ever reaches a writer. This step stays non-deterministic by design, and I'll come back to why.
From there, Claude instantiates a new Asana task from the BLOG task template through Connect AI's access to Asana, sets the publication due date, calculates draft and review due dates in business days, assigns the review subtask to the right person, and writes the task description with a working SharePoint link. This half of the workflow is deterministic: the same brief and the same due date produce the same task structure every time, which is exactly what you want from work that runs every month regardless of who's watching.
I still review the task set before it goes live. Some brief-quality calls are close enough that I want eyes on them, and I'd rather catch a mismatch before a writer builds three drafts around it. The system accelerates the work. It doesn't replace the judgment that decides whether the work is good.
How it was built: the exploratory phase
None of this started as automation. The first session was two users, one of them an LLM, sitting down to figure out what was even possible. Claude explored the Asana schema through Connect AI, found the BLOG task template ID, discovered the project and section IDs, and worked through creating a single task end to end while I watched and corrected. Every step of that first session sat at the non-deterministic end of the spectrum, because neither of us knew yet what the workflow needed. All told, Claude and I spent about 2 hours exploring and refining its model of the connected systems and mapping out the tasks it needed to perform.
It's worth noting that the setup for this exploration was shortened thanks to each underlying system being connected in Connect AI. The MCP configuration is ready out of the box (including Universal Tools built just for this kind of exploration). All I had to do was sign into each system from Connect AI and Claude and I were able to get to work.
The second session is where most of the useful failures happened. Claude calculated a due date's day of week by reasoning about it mentally and got it wrong, not once but twice in the same conversation, before I pointed out that January 21 was a Wednesday, not a Tuesday. When I asked Claude to update a task's description with the SharePoint link, it overwrote the entire Notes field, replacing a structured Background and Resources and Template layout with a single line. It happened again on the very next task, because the fix I'd given Claude addressed the immediate error rather than the pattern behind it. SharePoint's document search failed when I gave it the exact filename and only succeeded once I broadened it to a handful of keywords. A SharePoint link with an unencoded space broke the hyperlink in Asana entirely.
Each of these looked like a one-off mistake in the moment. Taken together, across eight sessions, they were something more useful: a map of every place the workflow needed a rule instead of a judgment call. A wrong day of week became a mandatory bash date command, verifiable and non-negotiable. A destroyed template became a fully documented Notes structure Claude had to preserve on every update. A broken link became a one-line encoding rule. None of this would have surfaced if I'd tried to design the API integration up front, because I didn't know what the failure modes were until Claude hit them. The exploration wasn't overhead. It was the design process, and it's the reason the spectrum framework insists that non-deterministic exploration isn't a phase to rush past. It's where the shape of the deterministic version gets discovered.
Connect AI's MCP interface is what made that exploration possible without a developer or an API document in sight. Claude could query Asana's schema, look at what fields existed on a template, and figure out how subtasks related to parent tasks, all through SQL against a connection I'd authorized once. The schema discovery that would otherwise take an engineer a day with Asana's REST documentation took Claude a few minutes of conversation.
The shift across the spectrum: from exploration to execution
Somewhere around the fifth and sixth sessions, the character of the work changed. By then, every recurring failure had been converted into an explicit instruction: pre-saved IDs so Claude never had to re-query the same catalog information twice, a business-day lookup table so date math never depended on mental arithmetic, a documented Notes template so an update could never again erase what it was meant to preserve. Session six is literally titled “Do the thing” in my chat history, because that's what I typed, and Claude created five tasks with no corrections needed.
The middle sessions are worth naming precisely, because they didn't jump straight from exploratory to deterministic. They sat in what the spectrum framework calls the hybrid zone: the structure of the task was fixed, but Claude was still exercising judgment inside it, deciding which brief best matched a topic, catching an edge case the instructions hadn't anticipated yet. That hybrid stretch is where most of the actual engineering happened, one correction at a time, until there was little judgment left that the instructions hadn't already accounted for.
What happened across those eight sessions wasn't the automation getting generically better. Each correction moved a specific step from something Claude had to reason about, in that moment, with room to get it wrong, toward the deterministic end, where the same input reliably produces the same output. That's the movement the first piece in this series described in the abstract, and this workflow is where I watched it happen step by step.
The mature version of this system isn't Claude chatting with Asana through MCP anymore. It's Claude running a script that calls Connect AI's REST API directly, which in turn talks to Asana, Excel Online, and SharePoint. In a conversation with my boss, Marie, about how the underlying architecture actually functions, she put it more precisely than I had: the MCP for Connect AI enables the work, but it's Connect AI through the API that actually does it, because at that point every skill is just an API call. That's the same relationship I wrote about in Claude Skills vs MCP, Better Together, and this workflow is the clearest example I have of it running in production. MCP got the workflow built. The MCP server and API are what runs it every month now.
What matters is that both interfaces sit on top of the same connection: the same authorized credentials, the same governed access to Asana and SharePoint, the same hundreds-strong source connectivity Connect AI provides across the board. That's the connectivity and control the spectrum piece argued every agentic workflow needs, regardless of where a given step sits. The platform didn't change between the exploratory phase and the production phase. Only the interface Claude used to reach it did.
What still requires the LLM, and always will
If most of the workflow is now deterministic code calling an API, it's fair to ask what Claude is still doing in the loop. The answer is two things, both of which sit deliberately at the non-deterministic end of the spectrum, and neither of which I want to move.
The first is judging brief quality. Deciding whether a brief is a strong enough foundation for a CData blog, whether the positioning lands, and whether the product angle is prominent enough to carry the piece requires reading comprehension and editorial judgment. There's no function that returns a quality score for a content brief. That evaluation is exactly the kind of work the spectrum framework says belongs with an LLM: the input is unstructured, the cost of an occasional miss is low because I review the output, and the task genuinely benefits from judgment rather than a fixed rule.
The second is competitor citation replacement. Finding a link to a competitor platform inside a brief, understanding what argument that citation was supporting, and identifying a third-party source that makes the same point without naming a competitor is pattern matching across unstructured content that depends on context every time. It's not a find-and-replace problem. It's a reasoning problem wearing a find-and-replace costume, and trying to codify it would degrade the quality of the substitution without buying any real reliability.
The goal was never to remove Claude from the workflow. It was to identify which steps could move toward the deterministic end without losing anything, the date math and the link formatting and the task creation, and leave the rest exactly where judgment still matters. That's the hybrid discipline the spectrum piece described: not pushing every step toward one pole, but placing each step where it belongs and building infrastructure that supports every position at once.
What I'd tell someone starting this today
If you're a content operations lead or a marketing ops manager looking at a similarly painful manual process, four things from this project are worth carrying into yours.
Start with MCP, not the API. The instinct to design the integration up front, before you've let an LLM poke around your actual data, produces a design based on guesses. Three sessions of exploration told me more about where this workflow would break than any planning document could have.
Treat every error as a specification, not a one-time fix. When Claude got a day of week wrong, the useful response wasn't correcting that instance. It was asking what rule would make the mistake structurally impossible going forward. Every failure in the exploratory phase is telling you exactly where a guardrail belongs, and where a step is ready to move toward the deterministic end.
Identify what has to stay at the non-deterministic end before you start codifying everything else. Before you convert a step into a script, ask whether it genuinely requires reasoning over content you can't fully anticipate. If it does, protect it. Those are the steps where the LLM is earning its place, and they're the easiest thing to accidentally engineer away in the rush to make everything deterministic.
Pick a connectivity platform that spans the whole spectrum. If the MCP interface and the API interface reach the same underlying data, with the same credentials and the same governance, moving a step from exploration to production is a code change. If they don't, every transition to production becomes a migration project, and you'll re-litigate access and permissions right when you thought you were done.
Frequently asked questions
This sounds like a lot of setup. Is it worth it for a content team?
The setup cost was real. Eight sessions across six weeks, with meaningful error correction along the way. But the payoff compounds, because each correction produced an instruction that made every future session faster and more reliable. By the end, five fully configured tasks with correct dates, working links, and reviewed briefs took one session with no errors. For a team producing 15 to 20 blog tasks a month, that breaks even in weeks, not quarters.
Did Connect AI require developer involvement to set up?
No. Authorizing Asana, Excel Online, and SharePoint through Connect AI happened once, without a developer in the room. After that, the SQL-based access layer meant Claude could explore what was available and I could build the workflow through conversation instead of reading API documentation. That's specifically what made the exploratory phase something I could do on my own, rather than something that had to go through IT.
What happens when the workflow breaks, and who fixes it?
It breaks two ways. The first is an upstream change, a SharePoint file that moves, a brief format that shifts, a new field in Asana. I catch those during my review of the task set before submitting, and the fix goes into the instruction document. The second is something genuinely novel that the codified rules don't cover, a case that belongs back at the non-deterministic end even temporarily. Claude handles that through the conversational interface, and if it turns out to be a recurring case, it gets added to the instructions too. The system is built to absorb corrections, not to break from them.
Can this be replicated for a workflow that isn't Asana or Excel?
The specific tools aren't the point. The pattern, exploring with MCP to find out what's there, then executing through the API once the pattern is known, works for any workflow where the data sources are accessible through Connect AI. With 350-plus connectors, most enterprise sources a content or marketing ops team would want to reach already have a supported path. This workflow is a template, not a blueprint tied to my particular tools.
Where this leaves the platform
The workflow described here runs on CData Connect AI, both the exploratory phase that built it and the production phase that runs it every month. If The Autonomy Spectrum gave you the framework, this is the same framework running against a real, messy, six-week build. If you're building AI workflows against enterprise data and want a platform that supports every point on that spectrum through the same governed connection, Connect AI is worth a free trial.
Explore CData Connect AI today
See how Connect AI excels at streamlining AI and business processes for real-time insights and action.
