When Cowork launched in January, I didn't understand the hype.
We'd deployed Claude Enterprise at Nayax. Hundreds of employees now had access to a tool most of them had only dreamed about — connected to Jira, Outlook, Teams, Confluence, Snowflake. People were doing things that were simply out of reach before. That felt like the win.
Cowork existed. I knew it. But the initial version was a local file-management tool — point it at a folder, let it sort your downloads. Useful, but not what I needed. And Chat, combined with the connectors we'd spent months carefully plugging in, was already doing incredible things. So Cowork stayed on the shelf.
Then the automation requests started coming in.
The Death Spiral
Every department had something they wanted to automate. IT wanted to auto-respond to incomplete helpdesk tickets. Finance needed meeting summaries routed somewhere useful. Managers wanted Jira tickets updated based on what happened in their standups. Everyone had a list.
We started evaluating n8n and Workato. That's when the death spiral began.
How does Andy from HR run a workflow on behalf of his credentials? How many environments do we need? Who educates the entire company on workflow variables, testing, monitoring? The n8n enterprise license alone wasn't cheap. And even I — with an engineering background and hands-on software experience — had struggled with n8n. I eventually pulled off what I needed by connecting it to Claude, but when it broke, I still had to debug it in the n8n portal. That's a learning curve that shuts most people out entirely.
I didn't see a way out. No clean answer, just more governance discussions.
The Moment That Changed It
On February 24, Anthropic shipped the full enterprise push for Cowork — plugins, deep integrations, and /schedule. My first reaction: "What could I actually do with that?"
I sat with that question. And then it clicked — not because of the scheduling feature itself, but because of what was already underneath it.
Cowork runs in each user's context. It logs in as them. It inherits their permissions. And it connects to every SaaS integration we'd spent the previous months approving and configuring — already scoped, already governed, already ours. No new environments. No credential sharing. No governance meeting required.
The automation platform we'd been debating how to buy was already deployed.
So How Does a Non-Technical Person Actually Build the Workflow?
That's the part that surprised me most. The governance problem was solved — but I still had a nagging question: how does Andy from HR actually build his automation?
The answer involves a mechanism where Claude watches your successful conversation, composes a reusable skill from it, then tests that skill against a clean session and produces an eval report. No nodes. No variables. No portal debugging.
Read the full breakdown on my blog →
The full post covers:
- How the "skill that writes skills" actually works in practice
- The specific automations I've been running for weeks (enriched work items, auto-responses, usage reports, meeting summaries → Jira)
- Why the connectors and governance we built over 3 months turned out to be the foundation for something none of us expected
- What rollout looks like next — and why it needs its own workshop
Top comments (0)