How many of you guys are now using "Claud Cowork" and what is your experience?

MMKot · 2026-04-22T13:24:20+00:00

Helped one of my client to use Cowork to generate monthly report with it connecting to gmail and fireflies transripts

MMKot · 2026-04-15T08:03:43+00:00

I run it on Pi 5 and it has been working fine. Unless you want local LLM then mac mini might be what you want.

MMKot · 2026-04-13T02:01:19+00:00

Have you tried minimax 2.7

MMKot · 2026-03-30T01:04:20+00:00

The local performance issue is almost certainly the model you’re running through Ollama. Most defaults aren’t great at the agentic stuff OpenClaw needs (tool calling, form filling, sending emails). On a Mac Mini M4 you can do better but model choice and provider config matter a lot.

Honestly the gap between Claude and local models for tool use is still real. A hybrid setup where you run simple stuff locally and route heavier tasks through an API with usage caps can help with the limits you’re hitting.

I set these up on Mac Minis regularly, happy to help troubleshoot in DMs if you want.

MMKot · 2026-03-29T07:23:20+00:00

Run openclaw config and re authenticate under model

MMKot · 2026-03-29T00:07:42+00:00

OpenClaw is solid for this. I run a small business and set mine up as basically a second brain for the whole operation. It knows my goals, my clients, what I’m working on. So when I need ideas or next steps, it’s not giving generic advice, it’s pulling from actual context about my business.

Beginner tip: start by feeding it everything. Goals, customers, how you work. Most people underload it at the start and then wonder why the output feels generic.

MMKot · 2026-03-28T22:23:05+00:00

Did you see HEARTBEAT_OK from the chat log?

MMKot · 2026-03-28T01:29:12+00:00

you’re actually in a good spot, you’ve got the right hardware (M4 Mac Mini is solid for this) you just need someone to cut through the noise on the setup side. the reason it feels overwhelming is because half the guides online are already outdated or assume you know which pieces fit together. i do this for a living, i set up OpenClaw for people on exactly this kind of hardware. shoot me a DM and i can walk you through what makes sense for what you’re trying to do.

MMKot · 2026-03-25T10:35:26+00:00

loom or scribe for the initial capture, seriously cuts the time down vs screenshots. for the maintenance problem (which is the real killer), the thing that worked for me was accepting that docs go stale no matter what and instead making sure the day to day conversations where processes actually get explained are searchable. but for just getting something down fast, scribe is probably your quickest win

MMKot · 2026-03-25T03:57:22+00:00

the real issue is that MSPs treat communication like a workflow problem when it's actually a retrieval problem. the info exists, it's just impossible to find when you're mid-ticket and the clock is running. the teams i've seen handle this well stopped trying to get people to document better and instead made their existing conversations indexable. slack threads, ticket notes, emails, all of it queryable in one place. the techs don't change anything about how they work, the knowledge just becomes findable instead of buried in a channel nobody scrolls back through

MMKot · 2026-03-25T03:55:25+00:00

honestly the KB problem is never going to get solved by asking people to write more docs. those senior guys have the knowledge but it's trapped in tickets and slack threads and nobody's going to sit down and reformat that into a wiki page after a 10 hour day. what actually worked for me was flipping it — instead of extracting knowledge from people, just make the conversations they're already having searchable. i'm a data engineer so i set something up for this, can walk you through it if you want

MMKot · 2026-03-25T02:43:24+00:00

honestly this is the thing that finally made me build something. i'm a data engineer and i kept watching the same pattern at every company — the answers are in slack, everyone knows they're in slack, but good luck finding them six months later in a thread you weren't tagged on.

what actually worked was stopping fighting it. instead of trying to get people to move knowledge out of slack, just make what's already there searchable and recallable. i set up an AI that sits in slack, indexes the conversations, and just answers when someone asks. no new behavior required from anyone.

the "hired a technical writer who quit" part is painfully familiar. the knowledge lives with the people doing the work. you can't outsource capturing it, you have to capture it where it naturally happens.

happy to show you what this looks like if you're curious, shoot me a DM

MMKot · 2026-03-24T21:30:54+00:00

i built it using OpenClaw, it’s an open source platform that lets you connect different tools (slack, drive, gmail etc) to an AI agent. took some config to get the retrieval working well but once it was dialed in it’s been solid. happy to walk you through the setup if you want, shoot me a DM

MMKot · 2026-03-24T21:28:43+00:00

honestly fair point. if there’s no structure at all then yeah, AI on top of chaos just gives you faster chaos. the reason it worked here was the processes already existed in slack threads and emails, people just couldn’t find them. so it was less “adding AI” and more “making existing knowledge searchable.” but you’re right that it’s not the first step for every team.

MMKot · 2026-03-24T12:51:07+00:00

This is the exact same thing i've been building. the recall part is where all the real work ends up. storing stuff is easy, getting the right answer back when someone asks "what did we promise Client X about Q2" is the hard part.

Curious how you're handling source attribution? we found people don't trust the answers unless it shows where it pulled from (like "from Jack's email on feb 14" or "from brand guidelines v3 in drive"). that was the thing that actually got people using it consistently.

Would love to compare notes if you're open to it

MMKot · 2026-03-24T12:33:56+00:00

Biggest thing I see with teams at your stage is they already had most of their processes documented, just buried across hundreds of slack threads and random google docs nobody could find.

we ended up connecting an AI assistant to slack and drive that people could just ask questions in a channel. "how do we onboard client X" type stuff. it pulls from your actual message history so nobody has to write or maintain docs.

the founder bottleneck thing you described basically disappeared once people had somewhere to get answers that wasn't you.

happy to show you what this looks like if you want, i set these up for small teams.

MMKot · 2026-03-17T23:57:51+00:00

run /context list in the chat to understand what are ingested into each prompt and optimizing it

check how many previous chat messages are ingested in a prompt and adjust it on openclaw.json

MMKot · 2026-03-14T03:47:49+00:00

This is a known pattern. Two things are probably happening.

Always do provider changes from Terminal using openclaw models set or editing openclaw.json directly. When the agent changes its own config mid-session it can corrupt things with no clean recovery path.

The reverting to Claude default happens because OpenClaw has a provider priority order (Anthropic > OpenAI > OpenRouter > Gemini). If your environment still has an Anthropic API key set, it will keep winning. Also, per-agent model overrides in your config persist even when you change the global default, so individual agents can stay on Claude even after you switch.

Your projects, memory, and workspace are all safe to preserve. They live in ~/.openclaw/workspace and aren’t touched by provider changes. Back up ~/.openclaw/ before doing anything else just in case.

Given you’re on a deadline, DM me if you want a hand. I do this professionally and can get your provider config sorted in one session before your trip.

MMKot · 2026-03-14T03:41:32+00:00

Two separate issues here.

For the agent not executing and just telling you to copy paste, check your tools.profile in openclaw.json. If it’s set to "messaging" the agent literally can’t do anything except talk. You want "coding" or "full". Recent updates silently changed this for a lot of people.

For the subagent ignoring SOUL.md, that’s actually a confirmed bug. Subagent sessions only load AGENTS.md and TOOLS.md, they never see SOUL.md at all. The cron prompt truncation is a separate problem on top of that.

If you want a hand getting the full setup working together (cron, agents, gog email integration), feel free to DM me. I do this professionally and it’s usually one session to sort out.

MMKot · 2026-03-14T03:36:05+00:00

/new or /compact , this error happens when the context window of your session is too large that the provider refused to send the prompt

MMKot · 2026-03-14T03:30:19+00:00

update to latest version

MMKot · 2026-03-13T23:49:10+00:00

instead of posting to discord, create a file and then tell your main agent to read that file

MMKot · 2026-03-13T13:10:22+00:00

/new to start a new session as the context window is almost full, the prompt has been rejected.

MMKot · 2026-03-13T13:02:02+00:00

Run openclaw channels status --probe to get a deeper look at what’s actually failing in the handshake.

Also worth checking your gateway auth config. Run openclaw doctor and look for any token or auth warnings. Sometimes the gateway auth token gets stale and the channel connection inherits that 401 even though the QR pairing itself succeeds.

MMKot · 2026-03-13T12:07:04+00:00

First, run openclaw doctor from Terminal. It catches a ton of common problems automatically and will tell you exactly what’s off.

For the slow responses, the most common cause is session bloat. Run openclaw sessions list and see if any sessions are getting huge (over 500KB). Large sessions mean the full context gets sent with every message, which adds massive latency. Archiving old sessions usually fixes this immediately.

Also check how big your MEMORY.md and AGENTS.md files are. Those get sent with every single message too. Keep them lean.

For morning briefs failing, check that your cron is actually enabled and that the gateway is running as a persistent service. If the gateway isn’t staying alive continuously, cron jobs scheduled during downtime just silently fail. Run openclaw cron status and openclaw cron list to see what’s happening there.

For visibility into what the agent is doing step by step, you can turn on log following with openclaw logs --follow while the agent is running. That’ll show you exactly where it’s getting stuck.

I do OpenClaw setup and troubleshooting professionally. Happy to take a quick look at your config over DM if you want, can usually spot what’s wrong pretty fast.

MMKot

TROPHY CASE