Welcome to a new edition of Coworkings AI!

Over the past few months, speaking with operators and consultants throughout the industry, the same AI questions come up in every conversation:

In this edition of Coworkings AI, we explore those questions using a real use case — Answering Member Support Queries — to show exactly how the AI implementation process works in practice:

6 steps for any operator to go from identifying the right tasks to building and iterating working AI agents.

Let’s dive in.

The starting point is identifying the workflows and processes that already exist and shape your space's operations.

Before thinking about AI agents, you need a clear workflow inventory of what your team actually does every week, and then document exactly how each task gets done. The best candidates for automation are tasks that repeat with high frequency, follow a predictable pattern, and don't require discretionary judgment on each individual case.

Start with the most repetitive ones. Ask yourself: what does your team do more than 5 times a day in a similar way?

Here are some potential starting points across coworking operations, specifically chosen because they show clear repetitiveness:

Once you've identified a candidate, document the real process exactly as a human executes it today, every step, every decision, every exception. What input arrives? What gets evaluated first? What decisions are made? What output is produced? What happens when something goes wrong?

Detailed mapping is what turns a vague task into an instruction an AI agent can actually follow. Without this step, the AI agent operates on assumptions.

Throughout this guide, we apply every step of the process to a real example (Member Support Queries) a repetitive task any coworking operation can relate to, showing in practice how to build and iterate a working AI agent.

Your community manager answers the same questions every single day: "How do I book a meeting room?" "My key card isn't working." "Can I bring a guest?"

These arrive via email, chat, and WhatsApp, all answered manually, one by one. High frequency, predictable pattern, no discretionary judgment required.

Here's what that workflow looks like step by step:

Once the use case and its specific task have been identified, the next step is to evaluate the current human-produced outcome.

This is your baseline. The agent's initial context comes from here.

Collect 75–150 real examples of how your team currently resolves that task, resolved tickets, sent emails, chat responses. This serves two purposes: it establishes the quality level the agent must match or exceed, and it becomes the training material you use to show the agent what doing the job well actually looks like.

Save the best examples as reference outputs. These are what you'll use to teach the agent what "correct" means.

Start by exporting the most frequently asked query topics from your coworking platform's help desk. You'll likely find that 80% of your tickets cluster around 5–7 recurring topics: room bookings, access issues, billing questions, guest policy, printing, WiFi, and onboarding.

For each of those topics, extract 15–30 resolved support tickets, that gives you a representative sample per category.

Then focus on the ones your best community manager handled. Notice the pattern: they acknowledge the issue first, give a direct answer, and always close with a next step. That structure is your baseline.

Save 5–8 of the best responses per topic as reference outputs. Those are what you'll show the agent.

An agent without context operates generically. Context is the real differentiator, an idea we explored in depth in a previous article.

Context is not a single document, it's a structured set of definitions that shape how your business operates and how the agent should behave within it.

These are the key categories to start building your coworking context:

Operators who treat context as a first priority build more reliable and scalable AI systems. Context is the real moat.

This is the most critical step, and the most frequently skipped. Without a clear definition of success, you can't evaluate whether the agent is performing well. 

Define specific acceptance criteria: tone, response relevance, information accuracy, policy compliance. For each criterion, establish a simple scoring system: 

Then iterate with the agent by showing it good and bad examples until those criteria are clearly embedded in the system prompt. The agent needs to know not just what to do, but how to distinguish between doing it well and doing it poorly.

Without this clarity, any output will seem valid, and that ambiguity is the root cause of 90% of automation projects that fail.

In the example below you can see how to audit each agent response using the scoring system, applying the acceptance criteria defined and adding qualitative feedback for each case.

Before running any cases through the AI agent, codify everything you've built so far into a structured skill. Think of the skill as a standing document that defines how the agent works, its role, its rules, and its limits.

A well-built skill contains these elements:

If you want to go deeper on skill structure, in previous editions we explored what a skill is and built two concrete examples — a member feedback skill and an inbound sales skill — both built with Claude and good references to explore.

Once the skill is written, run the first 20–30 real incoming cases through it manually. Don't automate yet. Read each output as if you were the member receiving it, score it against your acceptance criteria, and note what failed and why. This manual pass is the only way to catch what the skill gets systematically wrong before it runs at scale.

Run the first 25 incoming support messages manually through the agent. For each one, ask: Did it correctly identify the topic? Was the tone right? Did it escalate when it should have?

You'll likely notice the agent over-answers simple questions and under-escalates access issues. Fix both in the skill. Only once quality is consistent across the full sample do you package it and move forward.

Continuous feedback is what turns a generic agent into one that actually works.

When the agent fails, the incorrect output becomes the input for the next iteration. That error, well documented, is the most valuable instruction you can give. Don't treat failures as setbacks, treat them as the raw material for improvement.

With each fix, update the skill. The process repeats in four phases:

The initial prompt matters less than you think, it's the data the agent generates over time that tells you what new sources to add to the knowledge base and what to refine in the system prompt to keep improving it.

A member asks: "Can I add a second monitor to my dedicated desk?" The agent responds with the general equipment policy, but misses that this member is on an enterprise plan where the answer is different.

That's a failure. You document it: "Agent must check member plan before applying equipment rules." You update the skill. Next cycle, it gets it right.

What does continuous iteration actually look like when building AI agents? Here's what that process looks like across two real cycles:

In the example below, we define the initial knowledge base resources and build a first version of the system prompt for the Member Support Queries use case:

The image below shows the output of the member support agent for a specific user query, using the first version of the knowledge base and system prompt.

In the output example above, the "issues identified" section shows the improvements detected after the first analysis. In the example below, you can see how we added new resources to the knowledge base and iterated on the system prompt to better define the agent's expected behaviour and output quality.

The first version wasn't wrong, it was the starting point. Its outputs revealed exactly what was missing: plan-aware logic, concrete escalation ownership, and tone grounded in real examples. Two cycles in, the agent is already producing responses that match your team member. Run it again and it gets sharper.

What matters is not where you start, it's the process you run after it.

Every operator who has successfully implemented AI followed the same pattern, not because they had the best prompt or the most sophisticated tool, but because they treated each failure as an instruction and each cycle as an improvement.

The six steps in this guide are not a one-time checklist. You map the workflow, evaluate the baseline, define success, provide context, build the skill, and iterate. The operators who struggle are almost always the ones who skip the middle steps, jumping from "task" to "agent" without building the context, acceptance criteria, and validation layer in between. That gap is where most AI automation projects fail.

Start with one simple workflow. Run the process. Let the data tell you what to fix, and then do it again.

See you in the next edition 🙂