The move from one big prompt to deterministic code plus a reasoning model makes sense. Rules that must always hold, like permissions, are safer in code than in instructions the model might skip. Did they say how they test that agents still follow the rules after the instruction set grows?
The Salesforce Agentforce shift toward autonomous workflows is fascinating; are you seeing similar adoption patterns among fintech or financial services teams?
The two-token design is the part I'd copy: the operation runs only if the user's permissions, the agent's permissions and the data policies all allow it. It also answers the point in the article that a human is limited by how fast they can work and an agent isn't, but only partly. A permission check says whether one action is allowed, not whether the agent should do it 10,000 times. I'd add a limit per agent on how many records it can change in a period. Does Agent Identity cover rate or volume, or only access?
The "agent acts as Alex" setup collapses one person's whole permission set into a single task. Alex is limited by how fast a human can click; the agent is not, so a bad write with his credentials can be repeated across records before anyone notices. Agent Identity's two tokens only hold that line if the agent token is narrower than Alex's role and the pre-operation check is the intersection of user permissions, agent permissions, and data policy, not the skill text that lists APIs in order. I would test it as the same user, two agents, and a write that one identity must deny even when the user token would allow it.
"A prompt only tries to shape behaviour, it cannot enforce it" might be the most important sentence in agent engineering this year. Great detail on how they pulled the rules out of the prompt and into layers that can actually say no.
The most investable sentence in this piece is the one near the end: everything here is scaffolding around the model. If the durable value in agents is the deterministic layer — Agent Script, Data 360, the context engine, Agent Identity — then the moat is not the reasoning model, which gets cheaper and more interchangeable every quarter, but the unglamorous plumbing that makes a probabilistic system behave reliably in production. That reframes the 30%-reach-production statistic: the pilots that stall are not failing on model quality, they are failing on enforcement, identity resolution, and permissioning — exactly the four jobs Salesforce pulled out of the prompt. The Agent Identity piece is the one I would watch most closely as an investor. Giving the agent its own credentials, with two tokens instead of the user's full access, turns a security problem into a product surface: whoever owns the identity layer owns the audit trail, and the audit trail is what a regulated enterprise actually buys. The open question is whether this scaffolding consolidates into the platform or stays fragmented across point tools, because the Headless Toolkit and the discover-describe-dispatch pattern suggest the interface layer is still up for grabs. If agents end up living in Claude and Slack rather than in Agentforce itself, who captures the value: the model, the surface, or the plumbing in between?
This matches my experience with Claude Code. Once the instructions file gets long, the agent quietly skips things, so the rules I really care about end up as checks that fail the run instead of lines in a prompt. What I'd like to know is how Salesforce decides which rule stays in the prompt and which one gets moved into code.
The eight deserves a second look, because it's one team's experience rather than a law. The same post cites a benchmark where the best of 20 models followed just 68% of 500 instructions — following fades gradually, with no cliff at eight. Which makes the lesson simpler than a number: a rule the model can quietly skip is a suggestion. Putting the appointment lookup in code means it runs whether or not the model is in the mood.
"We put every rule in one giant prompt and hoped" is the most honest origin story in enterprise AI. Everyone did it. Most are still doing it, they've just renamed the prompt.
Also: 7 billion Agentic Work Units. A unit defined by the company that sells them. I've seen this movie — the number goes up, nobody asks what an AWU is worth.
The deterministic lookup only helps if the profile it runs against is the right person. The piece says match rules can be exact, fuzzy, or normalized, and the source records stay put while the agent reads the unified profile. A fuzzy phone match that joins two patients will make the before_reasoning appointment fetch succeed every time and still return the other Harper's slot. I would keep the match rule and the linked source ids on the profile the script reads, and fail the lookup when two candidates both cleared a fuzzy rule and nobody recorded which one was chosen.
With discover, describe, dispatch, a wrong answer can start with search ranking a near-duplicate skill first, and the final transcript hides that. Logging the ranked list from discover and scoring top-1 hits against a labeled set of requests catches it when someone adds a new skill with a similar description.
Agents dropping rules after about eight instructions matches what I've seen. Prompts give an agent intent, but rules that always have to hold belong in code and permissions. I start my agents read-only and widen access once I've seen how they behave.
The memory-versus-fact example needs a failure case: enrollment commits, but the request times out before the agent sees the result. I'd want the next turn to reconcile that enrollment by a stable operation ID before updating long-term memory or repeating the action. The before/after_reasoning blocks make execution order explicit, but the durable outcome across a lost response is a separate contract. Where is that receipt stored and checked?
Marcus, the lost-response case is the one I'd test first: kill the connection after the enrollment commits, then check the next turn looks up the operation ID and doesn't enroll twice or write a wrong fact to memory. I'd add a variant where the retry arrives after context was trimmed, since that's when the receipt is most likely to go missing. I keep an open checklist of tests like these here: https://huggingface.co/datasets/srinivaspadmanabhuni/agentic-ai-test-checklist-110
The two token check in Agent Identity is the part I'd love to see more on. Running an operation only when neither the user's nor the agent's permissions deny it gives you the intersection, which is right for actions. But the context engine also has a Govern step for masking and consent. Does that step use the same intersected permissions, or only the user's? If it's only the user's, an agent scoped to appointments could still get insurance details compiled into its prompt and repeat them in a reply, even though it could never call the insurance API itself.
The move from one big prompt to deterministic code plus a reasoning model makes sense. Rules that must always hold, like permissions, are safer in code than in instructions the model might skip. Did they say how they test that agents still follow the rules after the instruction set grows?
The Salesforce Agentforce shift toward autonomous workflows is fascinating; are you seeing similar adoption patterns among fintech or financial services teams?
The two-token design is the part I'd copy: the operation runs only if the user's permissions, the agent's permissions and the data policies all allow it. It also answers the point in the article that a human is limited by how fast they can work and an agent isn't, but only partly. A permission check says whether one action is allowed, not whether the agent should do it 10,000 times. I'd add a limit per agent on how many records it can change in a period. Does Agent Identity cover rate or volume, or only access?
The "agent acts as Alex" setup collapses one person's whole permission set into a single task. Alex is limited by how fast a human can click; the agent is not, so a bad write with his credentials can be repeated across records before anyone notices. Agent Identity's two tokens only hold that line if the agent token is narrower than Alex's role and the pre-operation check is the intersection of user permissions, agent permissions, and data policy, not the skill text that lists APIs in order. I would test it as the same user, two agents, and a write that one identity must deny even when the user token would allow it.
"A prompt only tries to shape behaviour, it cannot enforce it" might be the most important sentence in agent engineering this year. Great detail on how they pulled the rules out of the prompt and into layers that can actually say no.
The most investable sentence in this piece is the one near the end: everything here is scaffolding around the model. If the durable value in agents is the deterministic layer — Agent Script, Data 360, the context engine, Agent Identity — then the moat is not the reasoning model, which gets cheaper and more interchangeable every quarter, but the unglamorous plumbing that makes a probabilistic system behave reliably in production. That reframes the 30%-reach-production statistic: the pilots that stall are not failing on model quality, they are failing on enforcement, identity resolution, and permissioning — exactly the four jobs Salesforce pulled out of the prompt. The Agent Identity piece is the one I would watch most closely as an investor. Giving the agent its own credentials, with two tokens instead of the user's full access, turns a security problem into a product surface: whoever owns the identity layer owns the audit trail, and the audit trail is what a regulated enterprise actually buys. The open question is whether this scaffolding consolidates into the platform or stays fragmented across point tools, because the Headless Toolkit and the discover-describe-dispatch pattern suggest the interface layer is still up for grabs. If agents end up living in Claude and Slack rather than in Agentforce itself, who captures the value: the model, the surface, or the plumbing in between?
This matches my experience with Claude Code. Once the instructions file gets long, the agent quietly skips things, so the rules I really care about end up as checks that fail the run instead of lines in a prompt. What I'd like to know is how Salesforce decides which rule stays in the prompt and which one gets moved into code.
The eight deserves a second look, because it's one team's experience rather than a law. The same post cites a benchmark where the best of 20 models followed just 68% of 500 instructions — following fades gradually, with no cliff at eight. Which makes the lesson simpler than a number: a rule the model can quietly skip is a suggestion. Putting the appointment lookup in code means it runs whether or not the model is in the mood.
"We put every rule in one giant prompt and hoped" is the most honest origin story in enterprise AI. Everyone did it. Most are still doing it, they've just renamed the prompt.
Also: 7 billion Agentic Work Units. A unit defined by the company that sells them. I've seen this movie — the number goes up, nobody asks what an AWU is worth.
The deterministic lookup only helps if the profile it runs against is the right person. The piece says match rules can be exact, fuzzy, or normalized, and the source records stay put while the agent reads the unified profile. A fuzzy phone match that joins two patients will make the before_reasoning appointment fetch succeed every time and still return the other Harper's slot. I would keep the match rule and the linked source ids on the profile the script reads, and fail the lookup when two candidates both cleared a fuzzy rule and nobody recorded which one was chosen.
With discover, describe, dispatch, a wrong answer can start with search ranking a near-duplicate skill first, and the final transcript hides that. Logging the ranked list from discover and scoring top-1 hits against a labeled set of requests catches it when someone adds a new skill with a similar description.
Agents dropping rules after about eight instructions matches what I've seen. Prompts give an agent intent, but rules that always have to hold belong in code and permissions. I start my agents read-only and widen access once I've seen how they behave.
The memory-versus-fact example needs a failure case: enrollment commits, but the request times out before the agent sees the result. I'd want the next turn to reconcile that enrollment by a stable operation ID before updating long-term memory or repeating the action. The before/after_reasoning blocks make execution order explicit, but the durable outcome across a lost response is a separate contract. Where is that receipt stored and checked?
Marcus, the lost-response case is the one I'd test first: kill the connection after the enrollment commits, then check the next turn looks up the operation ID and doesn't enroll twice or write a wrong fact to memory. I'd add a variant where the retry arrives after context was trimmed, since that's when the receipt is most likely to go missing. I keep an open checklist of tests like these here: https://huggingface.co/datasets/srinivaspadmanabhuni/agentic-ai-test-checklist-110
The two token check in Agent Identity is the part I'd love to see more on. Running an operation only when neither the user's nor the agent's permissions deny it gives you the intersection, which is right for actions. But the context engine also has a Govern step for masking and consent. Does that step use the same intersected permissions, or only the user's? If it's only the user's, an agent scoped to appointments could still get insurance details compiled into its prompt and repeat them in a reply, even though it could never call the insurance API itself.