Launching today
MakersClaw
Hire AI employees that live in your Slack, Teams, Telegram
127 followers
Hire AI employees that live in your Slack, Teams, Telegram
127 followers
Hire AI employees that run 24/7 in their own container with their own memory. One-click into your Slack, Telegram, or Teams. Pre-built for support, sales, research, SEO, or anything you write yourself. Pay per call for the tools they use.
AskCodi
@shreyans_assistiv congrats on the launch! I'd definitely try the PA and the support template first. On sales, I'd actually be a little wary of having the agent interact directly with prospects. What are the guardrails/quality controls you have around that?
AskCodi
@denitsapenchevavaltchanova Thanks Denitsa! 🙏 Totally fair instinct — PA and support are the easiest day-one wins. On sales, the short answer: it's human-in-the-loop by default (drafts, doesn't send, until you trust it), it only speaks from the context you give it so it's not improvising claims, and you set hard limits on what it can't do plus when it hands off to a human. Every message is logged too, so it's never a black box. The goal isn't to replace your judgment on prospects — just to kill the busywork around it. Happy to walk you through the controls if you want to dig in.
Huddle01 VMs
@shreyans_assistiv v cool
the 'ai employee' framing is getting crowded fast - so many tools launched this month doing the same slack/teams bot thing. the per-call pricing on tools is the bit that'll catch people off guard when an agent loops or retries unexpectedly. what actually differentiates the memory layer here vs just wiring up a standard agent with a slack connector?
AskCodi
@galdayan Honestly, fair points. We're not trying to win the "another Slack bot" race - Slack/Teams is just the easy on-ramp. The actual bet is the ecosystem around the agents. On memory and the per-call cost problem you flagged, that's exactly what having a few ai researchers on team helps with, testing a few approaches to optimize and cut cost. No grand claims yet; we'd rather ship something that holds up than overstate it on launch day. Would genuinely value your eyes on it as it evolves.
AskCodi
Hey PH 👋 Sachin here, jumping in with the engineering side for anyone curious.
Each employee is a Kubernetes pod with its own filesystem and its own postgres-backed memory. State survives restarts and channel disconnects. Even a full redeploy. We chose this over a serverless function model because we wanted the agent to be a process you can talk to at 3 AM and have it remember the conversation from yesterday morning. Cold starts and stateless containers kill that.
For app integrations we run a hosted MCP layer at the workspace level. You OAuth once per app (GitHub, HubSpot, Zendesk, Jira, Asana, Airtable, Gmail, Outlook, Calendar, more) and any employee in your workspace can use the integration after that. Each MCP server is managed on our side, so there's no JSON config or token paste on yours. No re-auth per agent.
For configuration we built a chat-driven onboarding flow. Instead of filling forms to set up the employee's role, tone, and context, you talk to it. It asks the questions, you answer, it writes its own config record. The mental model is onboarding a remote hire rather than setting up software.
Skills are modular blocks of context the agent retrieves dynamically when a task needs them. Private skills stay scoped to your workspace. Public ones get installable by any maker. So the agent isn't carrying the whole brain on every call. It pulls the right context for the work at hand.
Two runtimes:
- PicoClaw runs on Python. Lighter, supports email channel and cron scheduling.
- Moltis runs on Rust. Heavier. Web dashboard, browser automation, voice (15+ TTS/STT providers), CalDAV.
Happy to go deeper on any of the architecture. Ask me anything.