Humalike x Hermes

I have several questions about how this plugin operates in large and highly active group chats.First, does the plugin have any limitations regarding the total number of group members or the number of simultaneously active participants? For example, in a group with dozens or even hundreds of members, where many people may be chatting at the same time, can the system still identify conversation structures accurately and operate reliably?Second, when multiple participants are speaking and several topics are developing in parallel, how does the plugin determine whether it should join the conversation or remain silent? Does it make this decision based on keywords, contextual relevance, direct mentions, participant identities, urgency, or some other form of conversation analysis?Third, in a fast-moving group chat, more than ten messages may be posted within only a few seconds. How does the plugin accurately determine which topic each message belongs to and avoid confusing an outdated discussion with a newer one?Fourth, the description states that the plugin simulates human typing speed, pauses, and response pacing. What happens if the plugin decides to respond to a topic and begins “typing,” but the discussion ends or shifts to another subject before the message is sent?Would the system:cancel the pending response;regenerate the response based on the latest messages;send the original response even though it may already be outdated; orreassess whether the response is still relevant before sending it?Finally, the plugin may split a response into one to three short messages. This may feel natural in a slow-moving conversation, but in a highly active group chat, those messages could easily be separated by messages from other participants.How does the plugin maintain the coherence and readability of its response in this situation? Can it automatically switch to a single complete message when the chat is moving quickly, or use features such as quoted replies, threaded replies, or direct mentions to make it clear that the messages belong to the same response?Otherwise, users may need to search through the conversation to locate each part of the plugin’s reply. This could make the response difficult to understand, reduce users’ willingness to read it, and negatively affect the overall group-chat experience.

The turn-taking and social memory pieces stand out to me. An agent knowing when to stay quiet, while remembering the people in a group, feels more useful than just giving it a friendlier tone.

I want to know whether the hardest part was making the agent more human, or making it less eager to participate.

congrats on the launch. the "who said what" memory question that hasn't come up yet: since it runs across Slack, Telegram and WhatsApp, if the same person messages the agent under different handles on two of those platforms, does Humalike link that back to one identity, or does each platform get its own isolated memory of that person? seems like it'd change a lot for someone who's in the same group across multiple apps.

"social intelligence" is the part I'd want a concrete definition of before buying in - is there an actual benchmark or eval suite behind that claim, or is it mostly vibes-based (agent seems less awkward in a demo)? proactiveness is even harder to score objectively since an agent that's too proactive just becomes annoying. curious what metric you're actually optimizing against internally.

decides when to speak is the whole game for me. i've killed more than one bot in a group chat because it replied to everything and drove people nuts. staying quiet at the right moment is way harder than having something to say. how does it learn a specific group's threshold, or do you set it?

Splitting those two apart is fair, and the interruption handling is the bit I want to poke at. When we did this we cancelled the in-flight generation whenever a new message landed, and the annoying part wasn't the cancel, it was deciding whether to restart from the new context or drop the turn, because on a busy channel restarting meant the agent never finished a sentence. Does yours re-run the decision after an interruption, or stay quiet for that turn?

Congrats team! 🚀 Love that you’re treating social skills as infrastructure rather than a prompt-engineering problem. Quick technical question: how does the Social Signals API detect things like typing pauses and deleted reactions? Does it need platform-level event hooks like Discord or Slack webhooks, or can it infer these from message streams alone? Curious how portable that is across stacks.

What I'd want to know is how long the decision takes. In a live group the window where a message is still useful is a couple of seconds wide, and every should-I-speak check we tried added another model call, so by the time it came back yes the thread had moved on two messages and the reply read as odd. Is the gating a small fast classifier sitting in front of the main model, or does the same model produce both the decision and the message?

Been waiting for something like this honestly. Social intelligence layer for agents is kind of missing piece in most setups. Does it handle context persistance across long sessions or its mainly per-conversation?

Finally someone tackling the awkwardness problem head on. Tried the API and the proactivity cues feel way more natural than the stiff reminders my agent used to send.

Congrats on the launch @marticarmona! Decoupling the behavioral layer from the LLM core is definitely the right architectural move for conversational agents.Because the plugin remembers 'who people are and what matters to them' in shared group settings (Slack, Telegram, WhatsApp), how does Humalike manage multi-user memory boundaries? If User A shares context in a 1-on-1 thread with the agent, how does the underlying knowledge graph prevent that memory from surfacing in a shared team or family group chat where User B is present?

A suggestion from someone who works with voice agents a lot: it would be great to see a turn-taking or interruption handling module exposed through the API. Right now most stacks handle barge-in in a pretty mechanical way, so a behavioral layer that knows when to pause, yield, or gently hold the floor would be a really meaningful addition.

the 'decides when to speak' bit is the whole game imo. most agents in a group chat have zero restraint and just talk over everyone

Congrats on the launch! The behavior layer being separate from the model is interesting. Everyone tunes what the agent says, few teams touch when it should shut up. Are you guys biasing it toward silence by default? Socially that feels right, but the failure mode I'd worry about is probably the false negative, the message it should've jumped on and skipped instead