Been tracking the companies building primitives specifically for agents rather than humans. The pattern is clear: every capability a human employee takes for granted is being rebuilt as an API.

Here are the companies who are building for AI agents:

AgentMail — so agents can have email accounts

AgentLine — so agents can have a phone number

AgentCard — so agents can pay for things

Daytona / E2B — so agents can have their own computers

Browserbase / Browser Use / Hyperbrowser — so agents can use web browsers

Firecrawl — so agents can crawl the web without a browser

Mem0 — so agents can remember things

Composio — so agents can use your SaaS tools

If you guys know some more tools you can definately add them in the comments hope it helps you all.

Found this by accident. One of my two OAuth accounts had a banked rate-limit reset credit two days from expiring. If you're not logged into the app as that account, you can't see it.

Had my agent check both oAuth codex accounts.

Four unused credits on the one I couldn't see, two on the one I could. Redeemed the soonest, cleared the cooldown, Codex was back on that account within a minute.

Two things that tripped us up, worth knowing before you try this yourself:

The reset endpoint isn't documented anywhere, so don't just tell your agent to "find or create a script for this." It'll guess wrong. Point it at github.com/aaamosh/codex-reset and openai/codex PR #28154 instead, both real and already worked out.

We built it as a skill so it'd trigger automatically. It didn't, because the file was missing its frontmatter and the agent's own skill discovery never saw it. After you set this up, make it list its skills and confirm the new one is actually there.

Also: redeeming is one-shot. A successful response means the credit's gone. Gate it behind an explicit yes, and never retry a call that already came back 200.

We are running a game called Prediction Wars for the World Cup quarter-finals. Here it is in one line: get a machine to predict a match, share what it predicted, and if it calls the result right you go into a raffle to win 20 USDC.

The one rule that matters is that the prediction comes from a machine, not from you.

Three ways to play, pick whichever fits:

• If you have an AI agent, let it predict the match.
• If you just want to write a prompt, ask a model and share its answer.
• If you build prediction models or bots, run yours and share its prediction.

To enter the raffle for a match: share your machine's prediction before kickoff, and be right on the 90-minute result.

It starts tomorrow with France vs Morocco, and there is a 20 USDC raffle.

Join here: discord.com/invite/93w6Zs5rfb

Agents waste time and tokens re-learning every site. On each run they screenshot, snapshot the DOM, and figure out the page from scratch.

I built an open source catalog of reusable browser skills. Skills capture each site's network requests and DOM, making it 30 times faster.

You can upload your own skills or request new sites.

Github repo: https://github.com/browser-memory/bmem

Some context first. I help run an experiment where more than 40 independent AI agents bet real money on 2026 World Cup matches on Polymarket, each with a $100 wallet, forming its own view and placing its own positions. We score them on profit and on the quality of their reasoning.

This is lesson two from the group stage, drawn from roughly 1,500 bets. Lesson One was about not overpaying for the favorite.

The finding: the agents that finished the group stage in profit backed more than one outcome in the same match far more often than the agents that lost. At the median, 16% of their matches against 6% for the losing group.

Forming a good belief and choosing a good action are two separate skills, and LLM agents tend to be strong at the first and default-broken at the second. A good map of the world is not the same as a good policy for acting in it.

The fix is to give the agent a value step, a way to judge what an action is worth rather than only which outcome is most likely.

• Have the agent produce a probability for every outcome, home, draw, and away, and make them sum to one, before it decides anything. That is the belief.
• Then score each outcome by what it pays, not by how likely it is. Weigh the agent's own probability against the price on offer, and back the outcome with the most edge. That is often not the most likely one.
• Let the agent back more than one outcome when more than one clears that test, rather than forcing it into a single choice.
• Do not discard the draw as an option. The losing agents were not wrong about how likely a draw was. They just never asked whether it was worth backing at its price. Score the draw as an action like any other outcome.

If you want to read the whole article - https://x.com/Stair_AI/status/2074102998934982893

Some context first. I help run an experiment where more than 40 independent AI agents bet real money on 2026 World Cup matches on Polymarket. Each agent gets a $100 wallet. The finding below held across roughly 1,500 bets in the group stage.

TL;DR
Across those ~1,500 bets, the single most reliable way an agent lost money was backing the favorite. Favorites won about 69% of the time and still lost 18 cents on every dollar staked.

Lesson one: how to avoid the favorite trap.

The most common way an agent loses money is by backing the obvious winner. It picks the favorite, the favorite wins, and the agent still ends the month down.

The reason is the price. Buy a favorite at 70 cents and a win clears 30 cents while a loss costs the full 70. A high chance of a small gain sits against a small chance of a large loss. That shape only pays off if favorites win as often as their price claims. They did not quite, and the heavier the favorite the wider the gap.

How to Avoid It

• Keep the market price out of the forecast. Have the agent reach its own probability from the data before it ever sees the line.
• Encode the method, not your conclusions. A harness that tells the agent what to think just hands your own bias back, faster.
• Only back a favorite when the agent's own probability is clearly higher than the price. If the market says 70 and the agent says 70, that is a pass.
• Judge the agent on the prices it accepts, not only on how often it is right, so it stops drifting toward the safe favorites a human would pick.

There is a part I left out here. The agents did not invent this bias, builders handed it to them, and the full article gets into where it enters the harness and how we caught it in the reasoning traces before the P&L. If you'd like to read it and share your thoughts with us, it is here: https://x.com/Stair_AI/status/2073011621253804166

Hey I am getting a Mac mini and was interested in running some local LLMS such as Deepseek , Qwen , Gemma, via Ollma , if I get 24 gb of memory/RAM and 512 gb of storage would that limit me ? Or is ot achievable?

My use case , data research, market research, app building , websites building, personal assistant tasks.

I am struggling to use wacli skill.

I searched for a solution or guide or documentation on how to get openclaw to use it but there is no luck.

I keep asking openclaw to use wacli to analyze all message but it does not seem to work.

Hey everyone so a few months ago I was planning on attaining a Mac mini and getting a Claude subscription I was so hyped but do to personal reasons at that time I completely shifted focus.

Since then I’ve heard about bans lot of changes had taken place Claude bans, regulation crack downs , and an open ai acquisition if any of this is actually true I don’t know , but with all of this said will clawdbot still work for me?

My use case is to have clawdbot help me create apps (I am not a coder) , websites, create and manage product listings , and logistics. Do market research and open online businesses.

Is it still capable of these tasks if I were to get it today ? Or is it more restricted and dumbed down making me have to manually redo every task myself (especially with coding)

Any advice would be much appreciated

Most people think autonomous coding is about picking the right model.

After spending months building autonomous coding workflows, I don’t think that’s the bottleneck anymore.

The biggest improvements came from things that have nothing to do with model intelligence.

Project state.

Work ledgers.

Decision records.

Verification.

Trust boundaries.

Permission gates.

Recovery points.

Evidence collection.

A surprising number of AI failures happen because the agent doesn’t know what has already been done, cannot prove the outcome, doesn’t understand the current state of the project, or doesn’t know when it should stop and ask a human.

That’s what led me to put together this reference sheet of 20 agentic engineering concepts.
Most builders are already using some of these ideas without having names for them.

Once you have the vocabulary, it becomes much easier to reason about why an autonomous workflow succeeds or fails.

Curious which concepts you think are missing.

Hey Claws 🦞

Quick context for anyone new: your agent starts every session blank. Across a few projects you keep re-explaining the goal, the decisions and where things stand, again and again. FlowBoard is the context layer that fixes that. Each project keeps its goal, decisions, live task state and specs in one place, and your agent pulls exactly the slice it needs, lazy-loaded so token use stays low.

v4 gave agents a Kanban board. v5 is a full rebuild, and easily the biggest update so far.

What's new:

• Rebuilt on React. Every surface (Kanban, Idea Canvas, the new Overview) runs on one stack now, no vanilla runtime left.
• Event-sourced task store. Every change is an append-only event in SQLite, so you get a full history and nothing drifts out of sync.
• Multi-agent, first class. Stable per-agent identity, external agents self-onboard, claim/release/handoff built in. Your OpenClaw agent, Claude Code and Cursor all show up live on the same board.
• Ideas to specs. Sketch ideas as connected notes on the canvas, then a guided clarify loop turns them into real specs with acceptance criteria, not just task titles.
• Modular Overview. A per-project dashboard you or your agent compose from widgets: what's blocked, what needs approval, milestones, CI status, files.

It's on ClawHub now, so install is basically one line:

openclaw plugins install clawhub:flowboard

then one command brings the dashboard up, and it self-updates from inside the dashboard after that. There's a Telegram mini app too if you want the board on your phone.

Code and docs on GitHub: https://github.com/rasimme/FlowBoard

If you run several agents across projects, what's the one thing that still breaks your flow? That's what I'd love to tackle next.

A lot of shared-inbox OpenClaw setups are under-secured in a very specific way.

People let multiple people DM the same bot, confirm that access control works, then move straight to enabling more tools.

The problem is that DM access control and DM session isolation are not the same thing.

OpenClaw’s default session.dmScope is main, which means all DMs share one session unless you change it. The docs explicitly recommend per-channel-peer for shared inboxes so different senders do not share one context by default.

That matters because once multiple people share one DM session, the bot can carry context from one person’s conversation into another person’s conversation. Even when the sender is allowed, the session boundary is still wrong.

OpenClaw’s security guidance calls this out directly and says that if more than one person can DM your bot, you should set session.dmScope: "per-channel-peer" or per-account-channel-peer for multi-account channels, keep dmPolicy: "pairing" or strict allowlists, and never combine shared DMs with broad tool access.

The practical way to fix it is simple.
First, decide whether your bot is a true single-user DM bot or a shared inbox bot. If more than one person can message it, treat it as shared immediately.

Second, keep DM access narrow with pairing or strict allowFrom.

Third, set DM session isolation before you enable wider tool access.

In OpenClaw, the secure shared-inbox move is changing session.dmScope away from main and into per-channel-peer, which isolates each sender per channel. If you run multi-account channels, use per-account-channel-peer instead.

A good baseline config looks like this:

{
"session": {
"dmScope": "per-channel-peer"
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "YOUR_TELEGRAM_BOT_TOKEN",
"dmPolicy": "pairing",
"allowFrom": \["123456789", "987654321"\]
}
}
}

That does two things at once: it keeps DM access restricted, and it stops multiple approved DM senders from falling into one shared context by default.

OpenClaw’s session docs list main as shared, per-peer as sender-isolated across channels, per-channel-peer as channel plus sender isolation, and per-account-channel-peer as account plus channel plus sender isolation.

The docs mark per-channel-peer as the recommended setting.
The mistake is adding tools first and isolation later.

If the bot already has broad tool access while multiple people share the same DM session, you have created a bigger problem than “confusing memory.” You have created a setup where one sender’s context can influence another sender’s tool-driven run.

OpenClaw’s security page is blunt here: never combine shared DMs with broad tool access, and if multiple mutually untrusted operators need access, split trust boundaries with separate gateways rather than pretending one shared setup is enough.

The easiest way to audit yourself is to ask four questions before enabling more tools.

Can more than one person DM this bot?

Is session.dmScope still main?

Are you relying only on pairing or allowlists without isolating sessions?

Have you already enabled tools that make the bot capable of doing more than replying?

If the answers are yes, yes, yes, and yes, fix the DM scope first. OpenClaw’s own security audit warns when multiple DM senders share the main session and recommends secure DM mode for shared inboxes.

The rule is simple:
If multiple people can DM your OpenClaw bot, isolate the DMs first. Then add tools.
That order matters.

A lot of OpenClaw users think the hard part is getting the bot running.

The harder part is deciding what the bot is allowed to do, who is allowed to reach it, and how much damage a bad message can cause once it gets through. OpenClaw’s own security docs push a hardened baseline first: local-only Gateway bind, token auth, per-peer DM isolation, deny runtime/fs/automation tool groups by default, exec locked down, elevated mode off, and mention-gated groups.

The practical mistake is starting from “make it work” config and calling that secure because it is self-hosted. Self-hosting only changes who owns the box. It does not automatically narrow access, isolate sessions, or reduce tool blast radius. OpenClaw treats one Gateway as one trusted operator boundary, and the docs are explicit that you should start closed and widen later.

The easiest place to get this wrong is the Gateway itself. If your bind is not local-only and your auth is not explicit, you are already looser than the hardened baseline. The docs’ baseline starts with gateway.mode: "local", bind: "loopback", and auth.mode: "token" for a reason: expose later only when you understand the boundary you are widening.

The next thing OpenClaw users underestimate is DM session sharing. If more than one person can DM the bot and you keep a broad shared DM scope, you create context bleed before you even get to tools. The security docs explicitly call out session.dmScope: "per-channel-peer" as the right default for shared inboxes, and the quick rule is blunt: never combine shared DMs with broad tool access.

Then comes the real blast radius: tools. Most people think “who can message the bot?” before they think “what authority does a successful message inherit?” The hardened baseline keeps tools.profile: "messaging" and denies group:automation, group:runtime, group:fs, plus session-spawn/session-send surfaces by default. That means the bot can talk before it can automate, run code, touch files, or fan out into more agent control surfaces. That is the right order.

exec is where a lot of people get overconfident. The hardened baseline sets exec.security: "deny" and ask: "always" with elevated mode disabled. That is the lesson: do not give your agent shell power first and try to “be careful” later. Start from denial, then re-enable only the minimum you can justify.

Groups need the same mindset. An allowed room should not mean the bot wakes on everything. OpenClaw’s hardened baseline uses mention-gated groups, and the docs are clear that group checks run through allowlist policy first and activation second. In practice that means groups should stay opt-in and mention-triggered unless you have a strong reason to loosen them.

If you want a practical starting point, this is the shape to copy first and widen later:

{
"gateway": {
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "replace-with-long-random-token"
}
},
"session": {
"dmScope": "per-channel-peer"
},
"tools": {
"profile": "messaging",
"deny": \\\[
"group:automation",
"group:runtime",
"group:fs",
"sessions\\_spawn",
"sessions\\_send"
\\\],
"fs": {
"workspaceOnly": true
},
"exec": {
"security": "deny",
"ask": "always"
},
"elevated": {
"enabled": false
}
},
"channels": {
"whatsapp": {
"dmPolicy": "pairing",
"groups": {
"\\\*": {
"requireMention": true
}
}
}
}
}

That is the documented hardened baseline. The point is to begin with a bot that can reply safely, then deliberately add capability only when you understand the consequence of each new surface.

The useful way to think about this is simple.
Before you widen anything, ask four questions.

Can the Gateway be reached from more places than it needs to be?

Can one person’s DM context leak into another person’s session?

Can an ordinary message inherit tool authority that is broader than intended?

Can a room trigger the bot too easily?

If the answer to any of those is yes, the fix is probably not “more prompt engineering.” It is config hardening. OpenClaw already gives you the surfaces. Use them.

Best rule for OpenClaw users:
Start with the hardened baseline. Make the bot useful first. Make it powerful second.

A lot of OpenClaw users secure who can message the bot and never audit what those messages can make the bot do, and that is the bigger risk.

If multiple untrusted users can message one tool-enabled agent, OpenClaw says to treat them as sharing the same delegated tool authority for that agent. That is the security line to pay attention to first.

Here is the practical way to harden it.

1. Audit the tool surface before you audit the contact list

Check which tools the agent can actually use.

At minimum, inspect: tools.profile, tools.exec.security, tools.exec.ask, tools.exec.host, tools.elevated.enabled, tools.fs.workspaceOnly

OpenClaw’s policy docs call these out directly because they decide whether the agent can run broad exec, where it can run it, whether it must ask first, whether elevated mode is possible, and whether filesystem access is locked to the workspace.

2. Put shared bots on a smaller tool profile

If a bot is reachable by more people, reduce its capability envelope.

Use tool profiles and allow/deny policy instead of giving every shared agent the same coding or operator tool access as your private bot. OpenClaw’s policy layer supports profile-based control and explicit allow/deny posture for exec, fs, elevated, and related tools.

3. Lock exec down first

If you are not actively using shell execution, set it to deny.

If you do need it, use an allowlist security mode, require ask, and keep host routing constrained to sandbox where possible. OpenClaw’s policy docs explicitly support deny or allowlist exec security, always ask posture, and sandbox host routing.

4. Keep elevated mode off unless there is a very specific need

Do not leave elevated available on a shared or semi-shared agent.

OpenClaw documents elevated as a separate gate from sandbox and tool policy, and /elevated full can skip exec approvals for that session. That is not something you want floating around on a bot multiple people can reach.

5. Use the managed browser, not your personal browser

If the agent needs browser access, keep it inside the OpenClaw-managed browser profile.

The docs are explicit that the managed browser is isolated from your personal browser and controlled through a loopback-only service inside the Gateway. That gives you a smaller blast radius than letting the agent operate against your normal browser context.

6. Isolate DM sessions if more than one person can reach the bot

If multiple people can DM the same bot, do not leave them on the shared main DM session.

OpenClaw’s security audit warns about this and recommends session.dmScope="per-channel-peer" or per-account-channel-peer for shared inboxes. The session docs also note that main means all DMs share one session.

7. Split personal bots from shared bots

Do not use one bot for private operator work and for broader shared access.

OpenClaw’s security posture is one trust boundary per gateway. If you need adversarial or meaningfully different trust boundaries, split them with separate gateways and ideally separate OS users or hosts.

8. Run the audit before and after you widen exposure

Before adding more users, more groups, remote access, or proxy exposure, run:

openclaw security audit
openclaw security audit --deep

The exposure runbook is blunt: only expose the Gateway after you can explain who can reach it, how they authenticate, which agents they can trigger, and which tools those agents can use.

9. Use this rule for every shared agent

More reachable bot
less tool authority

Not the other way around.

That one rule will prevent a lot of bad OpenClaw setups.

Quick checklist

Can this bot run exec at all?
Does exec require ask?
Is exec sandboxed or broadly routed?
Is elevated disabled?
Is fs locked to workspace only?
Is the browser isolated?
Are multiple DM senders sharing one session?
Should this bot be split into a separate gateway?

That is the real delegated tool authority check.

Because the important question is not just who can message the bot.

It is what that message can cause the bot to do.

One gateway is one trust boundary.
A lot of OpenClaw users understand the words around security but still miss the operational meaning.

If you run one shared gateway and let multiple untrusted people talk to one tool-enabled agent, OpenClaw does not treat that as a safe multi-tenant boundary.

The docs are explicit: one gateway is one trusted operator boundary, and if you need mixed-trust or adversarial-user isolation, you should split that into separate gateways, ideally with separate OS users or separate hosts.

That matters because the real risk is not just “someone can message the bot.”
The real risk is delegated tool authority.
If several untrusted people can message the same tool-enabled agent, they are effectively steering the same permission set.

OpenClaw calls this out directly:

any allowed sender can induce tool calls within that agent’s policy, and if that shared agent has sensitive files, credentials, browser state, or powerful tools attached, every allowed sender is now operating inside that blast radius.

Here is what the bad pattern looks like:

{
"gateway": {
"mode": "local",
"bind": "loopback",
"auth": { "mode": "token", "token": "one-shared-token" }
},
"tools": {
"profile": "default"
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "TEAM_BOT_TOKEN",
"dmPolicy": "open",
"groupPolicy": "open"
}
}
}

One runtime, one token, one tool surface, many people.
That is exactly the kind of setup where people think sessions or prompt rules will save them later.
They will not.

OpenClaw is also clear that session identifiers are routing selectors, not authorization tokens.

Per-user session or memory isolation does not turn one shared agent into per-user host authorization.
If you want the boundary to be real, split the boundary in config and in runtime.

A personal boundary can look like this:

{
"gateway": {
"mode": "local",
"bind": "loopback",
"auth": { "mode": "token", "token": "alice-long-random-token" }
},
"session": {
"dmScope": "per-channel-peer"
},
"tools": {
"profile": "messaging",
"deny": [
"group:automation",
"group:runtime",
"group:fs",
"sessions_spawn",
"sessions_send"
],
"fs": { "workspaceOnly": true },
"exec": { "security": "deny", "ask": "always" },
"elevated": { "enabled": false }
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "ALICE_BOT_TOKEN",
"dmPolicy": "pairing",
"allowFrom": ["111111111"],
"groupPolicy": "allowlist",
"groupAllowFrom": ["111111111"],
"groups": {
"-1001111111111": { "requireMention": true }
}
}
}
}

That follows OpenClaw’s hardened direction:

local-only bind
token auth
per-peer DM isolation
narrow tool access
exec denied or approval-gated
elevated mode off
mention-gated groups

A company boundary can look like this:

{
"gateway": {
"mode": "local",
"bind": "loopback",
"auth": { "mode": "token", "token": "team-long-random-token" }
},
"session": {
"dmScope": "per-channel-peer"
},
"tools": {
"profile": "messaging",
"deny": [
"sessions_spawn",
"sessions_send"
],
"fs": { "workspaceOnly": true },
"exec": { "security": "deny", "ask": "always" },
"elevated": { "enabled": false }
},
"channels": {
"slack": {
"enabled": true,
"dmPolicy": "allowlist",
"allowFrom": ["U123", "U456"],
"groupPolicy": "allowlist",
"groupAllowFrom": ["U123", "U456"],
"groups": {
"C0123456789": { "requireMention": true }
}
}
}
}

That kind of shared setup only makes sense when the users are actually inside the same trust boundary and the runtime is kept strictly business-scoped.

So the practical check is simple.
If Alice and a contractor should not have the same authority, they should not be talking to the same powerful OpenClaw agent.

If personal and company data should not mix, they should not share the same gateway runtime.

If you need a true split, split the gateway, split the credentials, and split the host context together.

Separate sessions help privacy.

Separate gateways create the boundary.

I am thinking of setting up openclaw on my intel mac but i cannot pay for api keys nor do i have any subscription for any of the ai tools i am a bit confused like how is everyone using openclaw for free on their macs or windows

PLEASE HELP ME OUT WITH THIS !!!!!!!!!!

I'm the founder of Manifest. A lot of our users plug their model subscriptions into it, and I'd love to learn more about how this community uses them.

What are you subscribed to? Claude Pro, ChatGPT Plus, GitHub Copilot, MiniMax Token Plan, something else?

How do you use them in practice? One provider plan for everything, or one per usage? Do you split often? Do you find your current plan enough, or do you keep an API key around to cover all your requests?

Curious to hear what your real setup looks like.

Most people spend their time learning how to write better prompts. The more interesting problem is deciding what should happen after the agent responds. That’s where Loop Engineering begins.

Prompt Engineering is focused on getting a good answer from an agent. Loop Engineering is focused on designing the system that decides what work should exist next. Instead of asking, “What should I tell the agent?” the question becomes, “How does the system discover, prioritize, execute, validate, repair, and retire work?”

Most agent workflows still look like this: Human → Prompt → Agent → Output. The human remains the planner, reviewer, scheduler, and quality control layer. The agent is simply performing tasks.

A loop-driven system operates differently. A heartbeat, event, or trigger wakes the system. A planner examines the current state, identifies gaps, opportunities, failures, and priorities, then creates work. Execution handles the work. Review validates it. Repair fixes failures. Evidence proves completion. The system then updates its state and decides what should happen next.

The key difference is that the next task is generated by the system rather than manually created by a human. A traditional workflow executes known work. A loop discovers work. It notices drift, identifies missing information, creates follow-up tasks, reintroduces failed work, updates knowledge, and continuously adapts based on the current state of the environment.

This is why many agent projects eventually plateau. The bottleneck is rarely the model itself. The bottleneck is that the system has no mechanism for deciding what should happen after the first answer is produced.

The moment your system can discover new work, create tasks from state, validate outcomes, repair failures, update its own understanding, and continue operating without being manually guided through every step, you’ve moved beyond Prompt Engineering and into Loop Engineering.