Notes

Decision notes

Six short notes on the calls that decide an agent programme. One claim each, one thing we would refuse to build, and a link to the page that argues it. No fake metrics.

Send the brief

Note 01

Agentforce vs custom: three questions that decide it

Claim. You are not choosing a logo. You are answering where the users sit, where the system of record sits, and who must own the control plane.

Refusal. We will not quote Agentforce because a deck said “digital labor.” If the work is not in Salesforce, Agentforce is the wrong seat.

Share this

Three questions decide Agentforce vs a custom agent: where do the users already work, where does the record live, who owns the control plane. Hybrid is common. A partner who skips these is selling a demo org.

Agentforce vs custom agents →

Note 02

MCP is a connector standard, not a permission system

Claim. MCP lets a model call tools through one interface. That is useful. It is not auth, least privilege, or an audit trail.

Refusal. We will not treat an MCP server as a security model. Identity still sits in Salesforce sharing, your IdP, or IndyKite.

Share this

MCP is a bus, not a lock. Inventory the connectors. Scope them. Log them. Then decide permissions in the system that already knows who the user is. Point-to-point is fine for one agent and one API. The second runtime makes it debt.

MCP in production →

Note 03

Red flags in an Agentforce pitch

Claim. Partner vetting moved from Summit-tier logos to “have you shipped an agent.”

Refusal. Walk if they quote a fixed price before a data-readiness pass, propose more than three agents in v1, call it Einstein Copilot, or show a demo org instead of a production method.

Share this

Red flags in an Agentforce pitch: fixed price before knowledge and permissions are checked; more than ~3 agents in v1; “Einstein Copilot” used as the product name; no transcript review after go-live; no written no. Ask the 40 questions.

40 questions to ask an AI partner →

Note 04

Why we will not build more than three agents in v1

Claim. The first production agent teaches you grounding, identity, and ops. The fourth one multiplies the same unsolved problem.

Refusal. We will not staff a “digital workforce” program that starts with a portfolio. One use case. Then two more if the first one is reviewed in production.

Share this

If the first agent cannot inherit permissions or cite a source, ten agents will not either. We cap v1 at three. Context first. Platform second. The rest of the backlog waits until transcripts exist.

Pilot to production →

Note 05

Context first, platform second

Claim. You need grounded, permissioned context before Agentforce or a custom runtime. Sometimes that is Data Cloud. Sometimes it is clean Knowledge and a sharing model that already works.

Refusal. We will not start configuration while the agent would see the wrong records. You get a readiness note, not a demo.

Share this

Data Cloud is not a checkbox. It is one way to ground an agent. The question is what the agent is allowed to see and whether that data is clean enough to act on. If the context layer is missing, the platform choice is theatre.

Data readiness for agents →

Note 06

Rescue sequence for a stalled pilot

Claim. Pilots die on context, permissions, and ops — not the model. The sequence is assess, stabilize, then finish, cut, or rebuild.

Refusal. We will not add another model to a sandbox that never had an owner, a metric, or a transcript review. Same sequence for Salesforce orgs and AI pilots.

Share this

Stalled Agentforce / custom-agent rescue: 48-hour assessment, stop the bleeding, name the failure mode (context, owner, governance, integration), then finish, cut, or rebuild. Do not re-demo the same pilot.

Failed project and failed-pilot rescue →

The brief

Send the situation.

The honest no: if the work is a software factory with a named delivery date, we are the wrong partner.