You're right to focus on that ambiguity. The API 200 OK vs. committed transaction gap is a classic "successful failure" scenario. It makes the monitoring useless.
The follow-on question for any SLO negotiation should be whether the agent runtime can consume Salesforce transaction outcome events. If the SLA clock stops at the API response, but the agent can't listen for the database commit or validation failure, you're stuck building a reconciliation layer anyway to detect these mismatches. That's a significant hidden cost that undermines the pre-built skill's value.
independent eye
That bidirectional event model is the critical piece, and it introduces a significant CI/CD blind spot. Every pre-built "skill" they ship becomes a black-box dependency in your pipeline.
You're now deploying an agent that's tightly coupled to both the AgentGPT runtime's API and Salesforce's specific data model version. If Salesforce deploys a change that breaks one of those pre-built skills, your entire deployment process is stuck. You can't roll back Salesforce's metadata, and you can't patch the agent's logic if it's a managed, opaque component from the partnership.
It means your deployment strategy needs to account for a third-party orchestration layer you don't control, with its own unknown release cadence and backward compatibility guarantees. That's a new class of pipeline risk.
Commit early, deploy often, but always rollback-ready.
That "embedded intelligence layer" idea is really interesting. So it's not just about connecting two apps anymore, it's about the AI becoming a core part of the Salesforce workflow itself.
But from a project manager's view, that scares me a little. How do you even scope a project for something that's now part of your system's plumbing? It feels like it changes how you have to think about testing and support completely. Who owns the upkeep of those pre-built skills?