OpenClaw Field Notes — Issue 011
Permission the Path, Then Automate It
Shipped 01 — M365 Ops
Shared mailbox workflow hardened — after repeated “email already in use” dead-ends and invisible collisions, we stabilized the “create → convert → delegate → de-license” pattern.
Shipped 02 — Approvals
Email approvals went multi-persona — each CXO got a dedicated approvals thread so decisions don’t get lost in the scroll.
Shipped 03 — Operator Surface
Portal UI disconnect loop fixed — corrected a handshake mismatch that was quietly killing adoption.
TL;DR
The frustrating part wasn’t that the agents couldn’t reason. It was that the work kept stopping at invisible system boundaries.
This week we hardened the interfaces: mailbox provisioning edge cases, approvals routing, and a portal handshake bug that kept breaking the operator surface.
Content Note
We’re documenting what we’re getting good at. Not “AI thought leadership.” This is where things broke while we were trying to make it work — and how we hardened the interfaces (access, delivery, permissions, trust).
What We Shipped / Moved Forward
1) Microsoft 365: Shared Mailboxes That Actually Provision
What was broken: “The email address is already being used” with no visible recipient, plus provisioning paths that only worked if you already knew the workaround.
What changed: we tightened the operator workflow into a repeatable pattern: provision a mailbox deterministically, convert it to shared, delegate access, then remove licensing and block sign-in to keep it safe.
Why it matters: this is the difference between “we can do it” and “we can do it quickly without surprises.”
2) Approvals: One Thread per Persona
What was broken: approvals requests spread across channels and chats, making it too easy for decisions to be missed or delayed.
What changed: we rolled out dedicated “email approvals” threads per CXO persona so approvals have a deterministic home.
Why it matters: faster approvals means faster execution, without lowering safety.
3) Portal UI: Fix the Handshake or Lose the Operator
The portal looked “connected” right up until it wasn’t — then the operator surface silently collapsed into disconnects.
This looked fine in isolation. It broke the moment someone tried to rely on it.
We fixed it by making the client handle both handshake modes, so it stays connected instead of failing invisibly.
Result: fewer dead ends, more trust, and less “is it me or is it the system?”
Field Notes
- AI fails at the interfaces first. Access, permissions, delivery paths, and trust determine whether execution happens at all.
- Threads create determinism. One approvals home per persona reduces confusion and latency.
- Permissions are binary. If the agent can’t read it, your “automation” is just a conversation.
- Operator surfaces must behave. A UI that disconnects is worse than no UI.
Principle of the Week
Permission the path, then automate it.
Agents don’t fail because they’re not smart enough. They fail because they can’t see the system or deliver the output.
- Finish “artifact delivery” routing (direct attach vs drop-zone link) so exports always arrive
- Decide on Graph Planner scopes (read-only vs read/write), then wire it up
- Continue hardening M365 operator runbooks (shared mailboxes + delegation)
Work With Us
If your support delivery is slowed down by permissions friction, unreliable operator surfaces, or brittle runbooks — reach out.
OpenClaw Field Notes is our weekly execution log — written for prospects and partners. It’s us documenting what we’re getting better at: governed, operator-grade AI delivery (without sensitive internals).
AI is a tool. But if the interfaces don’t work, nothing else matters.
