Field Notes Day 2: From the Keyboard

Day 2 was two sessions for me: the Claudeforce MCP server demo, and a working session on the headless toolkit. MCP is the Model Context Protocol, the open standard an outside client uses to talk to a system on your behalf. I went in expecting plumbing. What struck me is how radical a shift they intend headless access to be, across the whole platform and across internal and external apps alike.

Flat illustration in forest green and warm sand of a person leaning back to haul a terracotta cord and plug across open floor toward a large sealed green box with an unused round socket on its side, an outlet panel on the wall behind them, and three more identical boxes standing further back with no one at them

The part that matters if you build for a living is what isn’t there yet. An ISV who sells a managed package can’t ship it with an MCP configuration ready to be turned on. ISV means independent software vendor, the companies whose products you install into your org as a managed package. Managed package support is going to trail the Agentforce implementation by a long way, and until it lands a package won’t carry its own connector. Every subscriber who installs one wires up the connection on their side.

That’s a gap, not a wall. The tooling for custom deployment is there today and it works. If you’re working one org at a time, go build. If you’re building something you mean to distribute, be clear about who bridges the gap: it lands on the admin in each subscriber org, and admins arrive at it with varying degrees of familiarity and skill. Plan for that stretch, and write the install guide for the admin who has never done this, not the one who has.

Which leaves the developer’s control panel where it already sits: the external client application, paired with the MCP configuration. Not something inside the platform. Worth sitting with, if you’ve spent the last several years moving work onto the platform rather than off it.

Yesterday I ended on two open questions, and one of them was what a skill is at the artifact level and who governs it. I got half an answer. They say skills definitions are coming to the Salesforce platform, which would make the admin the primary definer of the whole experience, with room to optimize token use and put guardrails around usage and governance limits. That settles who governs, and I think it’s the right call. It doesn’t tell me what the artifact is, or how I’d ship one I wrote myself.

So the advice I gave yesterday stands, and the clock on it is shorter than I thought. Settle who gets to write a skill and who reviews it before the install, not after. If the pen is going to be in the admin’s hand, you want to know what you’re doing with it.

Dave’s Day 2 dispatch, from the Architect’s Chair, is here.

Responses

Leave a comment

Your email address is not published, and we will not add you to anything. Required fields are marked with an asterisk.

Subscribe to our Updates

Sign up to hear from us!