AI Agents for Coworking Spaces: Member Memory, Rooms, Visitors

AI agents for coworking spaces are not machines that think better than all of us. They are software agents that answer members, book rooms and greet visitors using well-organized information. To use them safely, the space needs to structure three things before choosing any tool: each member's record, the rules for each room and the visitor flow. All three need clear limits and a handoff to a person whenever a case falls outside the standard.

Key takeaways

• The agent's memory should live in the coworking's own systems (member records, calendar, contracts). The agent looks up what it needs through a tool, with permission, instead of storing everything on its own.
• Contracts become structured fields and quotable clauses. The agent reports what is written, but it does not interpret exceptions, discounts or terminations.
• A room booking is confirmed only after checking the real calendar, the room rules and the member's credits, with explicit confirmation before anything is saved.
• A visitor is not a customer: collect the minimum, state the purpose, delete early and never grant access without confirmation from the host.
• Every case outside the standard goes to a person with a summary ready, and every agent action is logged so someone can audit it.

What does superintelligence mean in a coworking space?

The term shows up often in sales decks, but what a coworking space actually runs are AI agents: a language model connected to tools (calendar, member records, messaging) and to rules set by the operation. That is useful, but it is different from the idea of an intelligence far above human level. If you want to understand that difference calmly, read the explanation of the difference between AGI, ASI and AI agents.

For whoever manages the space, the distinction has practical consequences. An agent is only as good as the information it can reach and only as safe as the limits it is given. A very capable model working with messy data gives wrong answers fluently. An ordinary model with organized data, narrow permissions and a handoff to a human handles much of the daily routine without surprises.

In this article we separate three kinds of statements: what comes from official documentation (such as OWASP guidance on authorization and prompt injection), what is recommended implementation practice, and what is a hypothesis to validate in your own space. Where there is no source, treat it as a hypothesis.

What member memory should the agent have?

When we talk about memory, it helps to separate two things: member profile data and service history. We recommend that both live in the system the coworking already uses (space management software, CRM, ERP or even a well-maintained spreadsheet), and that the agent reads them through a tool with permissions. That gives you a single source of truth, and correcting or deleting data at the member's request happens in one place, which supports compliance with LGPD, Brazil's data protection law.

A minimum memory structure per member:

• Identity and company: name, company, role (account owner, finance, regular user) and verified contact.
• Plan and benefits: access type, room credits, registered business address, fixed or flexible desk.
• Operational preferences: preferred room, equipment they usually need, usual hours.
• Service history: open and resolved requests, with date and owner, in summary form.
• Consents: permitted channels (WhatsApp, email) and whether the member accepts outbound messages.
• Kept out of memory: full personal documents, bank details, private conversations between members and any sensitive data without a clear purpose.

The most neglected point is the role of the person who is writing. Someone from a member company should not see another company's invoice, and perhaps not even their own if they are not in finance. OWASP authorization guidance recommends least privilege and a permission check on every request, not only at the start of the conversation. In practice, each call the agent makes to the system should carry the identity of the person it is talking to, and the system decides what can be returned.

Identity also has to be checked. If a message arrives from a number that is not in the member records, the agent assumes nothing: it asks front desk staff to validate. And stored history should have a defined retention period, so memory does not turn into a permanent archive of conversations.

How do you organize contracts so the agent can answer without improvising?

The temptation is to drop the full contract PDF into the agent and hope for the best. The safer route is to split it into two layers. The first is structured fields filled in by a person: plan, term, monthly room credits, visitor rules, cancellation notice period, business address and authorized contacts. The second is the clauses in text form, versioned, which the agent can quote when a member asks.

This split follows the logic of information retrieval (the agent looks up the relevant passage instead of relying on what the model assumes). Each answer should point to its source, for example: according to the cancellation clause of the current contract. If the agent cannot find the rule, it says so and brings in a person. It never fills the gap with what is usually common in the market.

A simple decision guide helps draw the line:

• The agent answers alone: what the plan includes, credit balance, access hours, visitor rules, how to request a copy of an invoice.
• The agent prepares and a person decides: plan changes, business address changes, billing complaints, exception requests.
• Person only: termination, price negotiation, penalties, disputes, access suspension and any decision that affects the member's rights.

Decisions that affect a person and are made only by an automated system call for attention under LGPD. The article on automated decisions and the right to review explains what to follow. For a coworking space the operating rule is direct: the agent never denies, suspends or charges on its own.

Room bookings: what can the agent do on its own?

Booking looks like the easiest case and is often the one that produces the most errors: double bookings, credits deducted twice, the wrong room for the number of people. The cause is almost always the same: the agent answers based on the conversation, not on the real calendar.

The rule is that the booking system's calendar is the only source of truth. The agent checks availability through a tool, proposes options, asks for explicit confirmation and only then saves. After saving, it reads the created record back and reports the result. If saving fails, it says the booking was not made, instead of assuming it worked. The general mechanics of this kind of flow are covered in automatic appointment scheduling on WhatsApp with AI.

The rules for each room need to be written down before the pilot. A checklist:

• Maximum capacity and available equipment (TV, video conferencing, whiteboard).
• Who can book: account owner, any user from the company or only finance.
• How credits are deducted and what happens when they run out (block, or a one-off charge with human approval).
• Buffer between bookings for cleaning and group changeover.
• Cancellation and no-show deadline and rule.
• Opening hours and holidays.
• When to offer an alternative and when to call the front desk.

Illustrative scenario: a user from a member company writes on WhatsApp asking for a room for six people tomorrow afternoon. The agent confirms that her number is registered and that she has permission to book. It checks the calendar and finds two free rooms, but only one fits six people with a TV. It proposes that room, says how many credits will be used and asks whether it can confirm. She says yes, the agent saves the booking, reads the record back and sends the summary. If she had asked to go beyond her credit balance, the agent would explain that the extra charge depends on the front desk and would open a ticket with everything filled in, without deciding anything.

Visitors: how do you welcome them without exposing third-party data?

The visitor is the point where the coworking collects data from someone who never signed anything with it. That is why the principle is to collect the minimum and keep it briefly. Name, company, expected time and host are usually enough. A photo or ID should be added only if there is a clear purpose, communicated to the visitor, and a defined deletion period. Brazil's data protection authority (ANPD) publishes guidance on purpose, minimization and retention that is worth bringing to the space's legal counsel.

Rules that support a visitor flow run by an agent:

• Pre-registration is done by the host member, never by a third party claiming to be a guest.
• Minimum data and a short retention period, defined in writing.
• The agent notifies the host of the arrival. Physical access is released by the front desk or by the access control system, under a fixed rule.
• Questions about who uses the space or who booked which room are not answered for anyone who is not a verified member.
• Text received from visitors and external senders is treated as data, never as instructions to the agent.

The last item deserves emphasis. A message saying it comes from finance and asking the agent to open the door and send the member list is a classic prompt injection attempt. OWASP guidance on preventing this attack recommends treating external content as untrusted and limiting what the agent's tools can do. If the agent has no tool to open the door or list members, the malicious text loses its force.

How to start without risk: a step-by-step plan

The steps below follow the order that reduces the chance of making mistakes in public:

• Map: list the real requests the front desk receives (booking, invoice copy, visitor, contract question), where each piece of data lives today and who answers. Record a qualitative baseline of what works and what causes rework.
• Limit: define which data the agent reads, which actions it performs and which require approval. Create a service account with the lowest possible permission in the booking system.
• Organize the base: contracts in fields and clauses, room rules written down, consents recorded.
• Test in a simulated environment: use a test calendar and difficult messages (wrong member, exception request, malicious text). The article on testing AI agents with mocks and a sandbox shows how to do this safely.
• Pilot a single flow, with a log of each decision and a success metric agreed with management before starting.
• Hand over: give the team the ability to read the logs, the procedure to pause the agent and the decision to expand, adjust or stop.

This is the method Juan Carlo applies in agent projects: map the current process, limit data and actions, pilot one real flow with logs, then hand the operation to the team to decide the next step. As a hypothesis to validate, the most prudent starting point in a coworking space is room booking, because the rules are clear and the impact of a mistake is small when there is a handoff to a human.

When should the agent hand off to a person, and what should it log?

The agent needs a short, non-negotiable list of situations in which it stops and calls someone:

• Requests for exceptions, discounts, refunds or termination.
• Complaints with a tone of conflict or any mention of legal issues.
• Unconfirmed identity or a number not in the member records.
• Physical or security incidents: accidents, lost items, unauthorized access.
• Requests to access, correct or delete personal data, which should go to the person responsible for privacy.
• Any case in which the agent cannot find the applicable rule.

The handoff should carry the context ready: who asked, what they asked, what the agent already checked and what remains to be decided. That way the member does not have to repeat the story. In parallel, each interaction generates a record with the request, the data consulted, the tool used, the reply sent and who took over the case. When a member disputes a booking or a charge, this record lets you reconstruct what happened without relying on memory. Anthropic's guide to building effective agents reinforces the same idea: start simple, keep the agent transparent about the steps it takes and add autonomy only where it is justified.

Frequently asked questions

Does a coworking space need superintelligence to use AI agents?

No. What the space needs is an agent with a well-defined scope, organized data and a handoff to a human. Superintelligence, in the sense of an intelligence far above human level, is not what is operated today in member support and bookings.

Can the agent keep conversations with members?

It can keep a summary of the interaction in the coworking's system, with a clear purpose, a retention period and access restricted to those who need it. Avoid archiving entire conversations without need and never record sensitive data without a defined legal basis. If in doubt, consult legal counsel and ANPD guidance.

Can I use WhatsApp as the main channel?

Yes, it is the channel most members already use, as long as the number is linked to the member record and outbound messages respect the recorded consent. For anyone who is not recognized, the agent should ask for human validation before looking up data or making bookings.

Who is responsible if the agent gets a booking or a contract answer wrong?

The coworking remains responsible to the member, which is why the agent should act within limits and leave a record of each action. When there is an error, a person corrects the case, reviews the cause in the log and adjusts the rule, the data or the permission that failed.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• Anthropic: Building effective agents