MakersClaw

MakersClaw: Hire AI employees that live in your Slack, Teams, Telegram | Product Hunt

MakersClaw

Launching today

Hire AI employees that live in your Slack, Teams, Telegram

122 followers

Hire AI employees that live in your Slack, Teams, Telegram

122 followers

Visit website

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.

Overview

Reviews

Alternatives

Team

Awards

More

Free Options

Launch tags:SaaS•Artificial Intelligence•Bots

Launch Team

Subscribe

Promoted

Maker

📌

Hey PH 👋 Shreyans here, co-founder of MakersClaw. Sachin's in the thread with me today.

We started this because every "hire an AI agent" tool we tried felt like a chat widget with a coat of paint. It forgot the conversation when you closed the tab, it couldn't actually do anything in the apps you use all day, and we kept hitting walls trying to make one do real work.

So we built MakersClaw the way we wanted to use it. You hire an AI employee for whatever role you need: support, sales, personal assistant, research, SEO, or your own custom thing. Each one runs in its own container with its own memory, 24/7. You connect it to your Slack, Telegram, or Teams in one click. No bot tokens, no webhook config, no JSON.

Sachin's dropping a comment right below with how the guts work, the tools, the runtimes, the pay-per-call model. Read that if you want the mechanics.

Two specific things we'd love your honest take on:

1. Does the per-call tool model make sense to you, or is the mental shift from "subscribe to a tool" to "your agent pays per action" confusing the first time you see it?
2. We ship with four pre-built templates (support, sales, personal assistant, SEO). Which one would you actually try first, and which role do you wish we had a template for?

We'll be here all day. Pile on the questions and we'll answer everything.

Report

14d ago

@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?

Report

4h ago

Maker

@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.

Report

4h ago

@shreyans_assistiv v cool

Report

1h ago

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?

Report

4h ago

Maker

@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.

Report

4h ago

Maker

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.

Report

5h ago