A community manager that lives in your members’ chat.

When a member writes in, the agent already knows who they are: their role, where they joined from, and what has happened before. It pulls context from your CRM and from every past conversation, so nobody has to reintroduce themselves. This is the foundation every other capability builds on.

• member messages
• member joins

Every voice note, message and conversation adds to a standing profile: role, interests, what they need, who they know. The profile is never static; it updates as members talk. It is the memory the agent draws on for every introduction, event and follow-up.

• message received
• voice note received
• profile updated

Bios and tags do not have to be written by hand. The agent generates them from what already sits in your CRM, past notes and conversations, and keeps them current as new information arrives. A profile that would take an operator hours to write stays up to date on its own.

• note added
• conversation ends

Members do not always answer in text. When they send a deck, a PDF, a photo or a voice note, the agent reads it, pulls out what matters and writes it to the member’s record. Nothing sent has to be transcribed or filed by hand.

• file received
• voice note received
• image received

Some things only come out when someone actually asks. The voice interviewer places a short call, asks a handful of open questions, and structures the answers into the member’s profile. It proactively asks for an interview when a profile has gone stale or was never filled in.

• profile incomplete
• profile stale

A member can ask a plain question about the rest of the network and get back names, not just a search box. Each result comes with the reason it matched and a way to make contact, without the agent brokering an introduction itself. Access to results can be capped so it stays a helpful search, not an open directory.

• question asked
• member searches

Preferences, context and half-finished conversations carry across sessions and channels. A member does not have to repeat themselves the next time they write in. The agent picks the thread back up.

Whatever is added to your CRM or said to the agent overnight is folded into the searchable member file before morning. Search and matching never run against stale data. Nobody has to remember to refresh anything.

Members ask about policy, benefits, venues and house rules at all hours. The agent answers from your own documents, in the channel they already use, without anyone on your team typing a reply. It is the first line, not the last: anything it cannot answer goes to a human.

The moment a new member is added, the first message goes out in their chat, timed to your onboarding setup. It is the start of the onboarding sequence, not a one-off. Nobody joins and hears nothing.

A member can ask what is on, get the details, and say yes or no without leaving the chat. RSVPs land in your events tool automatically. Reminders and follow-ups run from the same record.

• event published
• member asks

Nobody is introduced cold. The agent explains why it is suggesting the match to each person separately, waits for both to agree, and only then makes the connection. If either side says no, nothing happens and nobody is told who declined.

• match found
• member requests introduction

A member tells the agent what they want to host, where and when. The agent checks it against your rules, invites the members it applies to, takes the RSVPs, sends the reminders and chases the no-shows. Your team approves or edits in one message, or lets it run.

• member proposes an event

Members do not have to ask to be introduced. On a recurring cycle, each one receives a curated suggestion drawn from the whole network, not just the people they already know. This is what keeps a large community feeling like a small one.

An unanswered suggestion gets a gentle nudge, not silence. If it still goes nowhere, the request is retired rather than repeated. Cadence limits mean a member is never chased past the point of usefulness.

• no reply after interval
• suggestion unactioned

After an introduction, the agent asks a short question in the same chat: did you meet, was it useful. The answer is recorded against both people and fed back into how future matches are scored. Every outcome makes the next suggestion better.

• introduction completed
• time elapsed since introduction

Onboarding is not a single message. It is a sequence timed against what a new member actually needs first: a welcome, an early introduction, an invitation to the next event, and a check-in later on. The sequence can be reordered or retimed for your community.

A community’s most useful conversations happen in small rooms. The agent forms boards or forums of a handful of members according to rules you set: who qualifies, how many sit together, how often they meet. It rotates the chair, drafts the agenda from what the group has said it wants, and finds a meeting time everyone can make, all inside the chat. When a board goes quiet it says so, and asks your team whether to refresh it.

• board due
• chair rotates

Dormancy is detected from the absence of activity, not guessed at. Once a member has been quiet for a set number of days, the agent reaches out with something relevant rather than a generic nudge. Many people come back from a single well-timed message.

• gone quiet
• member replies

A discount or benefit from a partner is only worth sending to the people it fits. The agent matches the offer against member profiles and delivers it to the right subset, in their own chat. Nobody receives an offer that has nothing to do with them.

• partner offer added
• match found

Booking a session with an advisor or expert works the same way as everything else: ask in the chat, get a time, done. It reads and writes to your calendar directly, so nothing needs a separate booking link. The conversation is the interface.

• member asks
• advisor available

Advisor time is finite. A running ledger tracks how many sessions each member has booked, so a handful of people cannot use it all up. Limits can be set per member or per period.

A booked session gets a reminder before it happens, in the same chat it was booked in. If a member cancels, the slot is released and a rebooking is offered rather than left to chase. Advisors are told the same way.

• booking confirmed
• booking cancelled

Not every member wants to follow every conversation as it happens. A digest gathers what mattered over the period and sends it as one message, at a cadence that fits the community. It is written from the same data as everything else, not a separate report.

A join anniversary, a funding round, a promotion: the agent notices and marks it, rather than letting it pass unremarked. The message comes from what it already knows about the member, not a generic template. Small recognition, sent on time, is part of what keeps a community feeling attentive.

When a member needs something the agent cannot answer itself, it can put the question to the rest of the network rather than leaving it unanswered. Replies are matched back to the person who asked. It turns a single question into a moment of help density.

• question unanswered
• member requests help

Your team can send an announcement to a chosen segment of people without leaving the tool they already use to review conversations. It goes out through the channel people already talk in, not a separate mailing system. One message, sent once, to the right people.

The agent knows what it should not handle alone. When that happens, the conversation and the member’s context go straight to a human, and the reply relays back in the same chat. A human is always one message away, never a dead end.

• escalation trigger
• member requests human

Every timed or triggered action in the system, from a welcome message to a dormancy check, runs through the same scheduling infrastructure. There are 39 scheduled job types live today. If a signal can trigger it, it can be built on this.

• signal fires
• schedule due

A member can set do-not-contact at any time, and every send path checks it before anything goes out. Preferences are enforced everywhere, not just in the flows that remember to ask. Consent is never assumed.

• preference changed
• message queued

Not every member wants the same channel for every kind of message. Preferences are stored per member and checked before a message goes out, so a reminder reaches someone the way they actually want to hear it. Nothing overrides a stated preference.

• preference set
• message queued

Frequency limits apply per member across every kind of outbound message, not just one flow at a time. A member who has already heard from the agent this week is not queued for another nudge because a different job fired. The limit is on the person, not the mechanism.

A suggestion is checked against a member’s stated preferences and recent history before it goes out. Matches that would clearly miss are stopped rather than sent and corrected afterwards. Fewer wrong introductions mean members trust the ones that do arrive.

If a member changes their mind partway through an introduction, they can withdraw and nothing further is sent. If a profile detail is wrong, correcting it in the chat updates the record immediately. Nothing is locked in once it is written down.

• member withdraws
• member corrects detail

Every suggestion the agent makes is recorded alongside what happened next: accepted, declined, completed, ignored. That record is what the matching engine trains on. The longer it runs on a community, the better its next suggestion gets.

A profile does not wait for a nightly batch to catch up with a member. A new conversation or a note added to your CRM triggers an immediate rebuild of that one record. What the agent knows is never more than one exchange out of date.

• note added
• conversation ends

A message that fails to send is not silently dropped. It is detected, diagnosed and retried automatically. If it still cannot go out, your team is told rather than left to find the gap themselves.

Delivery failures are not always permanent. The agent retries a failed send on a backoff schedule rather than treating the first failure as final. Only a message that keeps failing is escalated.

A failure that retrying cannot fix is not left in a log for someone to stumble across. It is posted to a Slack channel your team already watches, with enough detail to act on it. Reliability problems surface immediately, not at the next review.

The member graph and your CRM are checked against each other on a schedule, not left to trust. Anything that has drifted is reconciled automatically. The system of record stays a record either side can rely on.

Profiles and CRM records can drift apart when one side is updated and the other is not. Drift detection compares the two and flags the difference before it causes a wrong match or a stale answer. Small discrepancies are caught early rather than left to compound.

A record that has lost its member, or a job that never resolved, is not left cluttering the system. Orphaned records are found and cleared on a schedule. It keeps the graph accurate rather than accumulating debris nobody notices.

Some organisations need a guarantee that nothing sent to a model is kept afterwards. Requests can be routed under zero-data-retention terms to meet that requirement. It is a routing choice, not a change to what the agent can do.

Where a model must run somewhere the organisation controls, an open-source or locally hosted model can take the place of a hosted one. The choice sits underneath the agent, not inside its behaviour. You choose where the model runs; we swap it in.

Escalated conversations arrive in a Slack channel with the member’s context attached, not just a bare message. Your team replies in the thread, and the answer relays back to the member automatically. There is no separate inbox to check.

Nothing the agent learns stays only with the agent. Every interaction lands on the contact record in your CRM, and changes made there flow back the other way. Your team keeps working where they already work.

• interaction recorded
• record changed

The complete conversational history for any member is stored and searchable, not summarised away. Your team can look up exactly what was said and when. It is the record behind every other report.

• message sent
• message received

A running report covers how much activity is moving through the agent, without anyone having to query the message log by hand. It is the baseline view of what the community is doing. Deeper analysis sits on top of it.

The usage report breaks down into what members are asking about most, not just how many messages there were. It is drawn from the same message log, not a separate survey. Your team sees where attention and questions are concentrated.

Escalation rate is reported alongside volume and topics, so your team can see how much still needs a person and how that is trending. A rising rate is a signal worth a look, not just a number. It comes from the same log as everything else.

Beyond raw volume, engagement analytics scores how well the community is actually engaging: how many introductions land, how events convert, which members are drifting. It is built and tuned for your community rather than shipped as a fixed template. Your team uses it to decide where to focus next.

Not every community needs the same thing. Custom tools are built against your specific programme and added to the agent’s toolkit, rather than asking you to work around a fixed feature set. It is ongoing, not a one-off build.

A message does not have to go to everyone to be a broadcast. Your team can define a segment, by role, stage or activity, and send to just that group. It keeps announcements relevant to the people they are actually for.

The graph, the message log and the workflows run in infrastructure you control. Access can be revoked at any time, for any reason, without migrating anything first. Your data stays yours because it was never anywhere else.

New capabilities are built and shipped on an ongoing basis, and they reach existing instances automatically. Nobody has to request an upgrade or schedule a migration. The agent your community uses today keeps gaining capabilities without anyone doing anything.

Every community runs on a few rituals of its own: a cohort cadence, a partner programme, a way of pairing mentors. On the Operating System tier we build those as workflows in the same machinery that runs introductions and follow-ups, so they fire on the same signals, respect the same cadence limits and land in the same system of record. You describe the outcome in plain words; we build it, test it against your live data and switch it on.

• any signal you can name
• your calendar
• your CRM

The Operating System tier comes with people, not only software. A named team reviews what the agent did each week, tunes matching and cadence with you, and makes ongoing changes as your community’s needs move. Requests go into your team channel and come back as working changes, usually within a working day.

• a request in your team channel
• a monthly review

Some organisations want the outcome without the headcount. On the Operating System tier we can take the community manager’s seat: handle escalations, curate the introductions the agent proposes, host office hours and report to you on help density. You keep the people, the data, the channel account and the model keys.

• your programme calendar
• escalations the agent cannot close