The Agentic
AI Stack.

MCP versus direct APIs: Standardize the AI-facing boundary

An enterprise can connect each AI application directly to its REST or GraphQL APIs. That is often the right choice for a small, stable integration. As the number of AI hosts and business services grows, however, each custom adapter must maintain tool descriptions, input schemas, error handling and invocation conventions. MCP provides a shared protocol for the host/client-to-server boundary, including tool discovery and typed invocation. It reduces repeated integration work; it does not remove it.

Question Assistant example. The implemented MCP connector let ChatGPT and Claude reach the existing Question Assistant capabilities. An illustrative request travels from the host's MCP client to a discoverable assessment tool, then through the server to the existing backend API. Questionnaire records, job execution and business rules remain in Question Assistant. Results return through MCP to the calling host. The exact tool names and routing shown in the walkthrough are educational examples.

Discovery and invocation. A host can discover the tools a server exposes and inspect their descriptions and input schemas, then invoke an appropriate tool with structured arguments. The server still validates the request, binds the actor and tenant, enforces authorization, and calls the underlying service. Compatibility depends on supported protocol versions, transports and host capabilities. See the MCP architecture documentation ↗.

When direct APIs are preferable. Use direct APIs for application-to-application integrations, tightly controlled custom clients, fixed workflows with a small number of endpoints, or integrations requiring service-specific behavior with little benefit from dynamic tool discovery. MCP does not replace APIs, SDKs or backend business logic. Both paths need independently enforced authentication, authorization, input validation, logging and safe handling of side effects; MCP alone does not make an action safe.

Externalized agent prompt administration

Implemented in Question Assistant. The production Question Assistant included an administration UI that allowed administrators to inspect and fine-tune the master instructions for its three specialized agents: Extractor, Validator, and Evaluator. This made prompt maintenance an operational configuration capability, rather than requiring administrators to edit the agent code each time instructions needed adjustment. The user-facing Question Assistant and the administrative configuration functions were separate interfaces.

Relationship to orchestration. The admin UI manages the instructions each role receives. Orchestration coordinates when Extractor drafts, Validator checks evidence and Evaluator assesses quality, with human oversight. Changing an agent's instructions and changing the orchestration workflow are different operations. The diagram below shows configuration flowing from prompt management to the three roles; it does not assert a particular storage system, refresh mechanism or model provider.

Proposed safeguards and interfaces. Versioned prompts, diffs, rollback, approvals and separation of duties, regression datasets, audit history, fine-grained administrative permissions, and MCP-exposed administrative tools or Skills are recommended extensions. They are not claimed as historical implementations. The existing admin UI must not be confused with the proposed Question Bank Administration Skill.

Cross-platform case study: One supply-chain request, two integration patterns

Imagine a supplier-risk manager asks Salesforce Agentforce: “Which suppliers have overdue security assessments? Start one for Vendor ABC and keep me updated.”

Pattern A — MCP, the simpler proposed integration. Agentforce identifies the supplier using the data and permissions available to its execution environment. It invokes allowlisted Question Assistant MCP tools to start the relevant assessment, record a tracking identifier, and check progress. The existing Question Assistant backend remains the system of record for the questionnaire. The actual production integration would need compatible MCP transport, host authentication, service authorization, tool allowlisting and a clear actor/tenant mapping. Salesforce documents concrete constraints; teams must verify the current configuration rather than assume user-level delegated credentials are always available.

Pattern B — A2A, the proposed specialist-agent design. An Agentforce supply-chain agent discovers a dedicated Question Assistant Agent and delegates the complete assessment task. The specialist agent owns the assessment lifecycle, sends progress updates and returns an artifact with findings and citations. Agentforce decides what, if anything, may be written back to Salesforce under its own rules. This requires building and securing an A2A interface. Our original Question Assistant MCP server was not an A2A agent.

Both patterns are worth animating because they are not interchangeable. MCP is attractive when the calling agent should retain orchestration and invoke specific tools. A2A is attractive when a specialist agent should retain task ownership and exchange task state and artifacts.

A product evolution: One Question Assistant plugin, two Skills

The proposed installable plugin contains a Questionnaire Workspace Skill for employees and a Question Bank Administration Skill for approved content owners. The first is rooted in a capability that was implemented: launch assessments, list completed and in-progress work, inspect status and review answers through ChatGPT or Claude. The second extends the platform to maintain reusable questions and questionnaire sets: create, read, update, retire, clone, organize, version, review and publish.

Consider an existing 250-question cybersecurity template. An administrator requests a 150-question supplier-specific variation and a 75-question rapid assessment. Rather than modify an active template in place, the system should create draft versions that retain source-question relationships, validate required categories, check for duplicates, and route changes for approval. Existing assessment instances must remain pinned to the question set and version on which they started. A role check on every backend mutation is essential; hiding an administrator command inside a Skill is not security.

This pattern can eventually support cybersecurity assessments, supplier onboarding, AI governance reviews and other questionnaire families without rewriting the processing engine. The number of questions should be configurable rather than hardcoded.

Where agentic architecture ends and enterprise governance begins

The third article complements—not replaces—the ten-pillar trust architecture. Identity, data authorization, privacy, secure tool invocation, threat defense, source provenance, evaluation and auditability still apply. In fact, giving agents the ability to act makes those controls more important. An LLM can help decide which tool seems useful; an independent backend policy must decide whether invoking it is allowed. Plugins and Skills should be treated as executable integration surface area: review dependencies, instructions and permissions before installation.

For administrators, high-impact activities—publishing a question-bank version, deleting a shared template, bulk editing answers or exporting sensitive assessments—should be reviewed, attributable and reversible. For long-running work, checkpoints and idempotent commands prevent a model timeout from duplicating assessments. For agents that share context, the data-access boundary must remain intact even when one agent delegates work to another.

How the three-article series fits together

Article 1 — RAG: How an AI system finds and grounds information. Article 2 — Beyond RAG, Ten Pillars: How data, business meaning, privacy, validation and security make AI trustworthy. Article 3 — The Agentic AI Stack: How those trustworthy capabilities are packaged, connected, orchestrated, delegated and operated as enterprise workflows.

The common thread is the Question Assistant—first as a knowledge and answer-validation application, then as an enterprise trust design, and finally as an interoperable service reachable from ChatGPT, Claude and, in a proposed future design, Salesforce Agentforce.

Build specialized capability once. Connect through governed interfaces. Package repeatable workflows. Delegate only when the architectural boundary calls for it. Measure business outcomes and maintain human accountability throughout.

References (official product and protocol documentation)

• MCP tools specification ↗ — MCP tools, discovery and invocation.
• MCP architecture and authorization ↗ — Core protocol and authorization overview.
• OpenAI plugin architecture ↗ — Multiple Skills and MCP server in plugin.
• OpenAI Skills in plugins ↗ — Separation between Skills and MCP tools.
• Anthropic Agent Skills ↗ — Skill format and progressive disclosure.
• A2A Protocol specification ↗ — Task lifecycle, agent interoperability.
• A2A core concepts ↗ — Agent Card, Task, Artifact definitions.
• Salesforce MCP for Agentforce ↗ — Product feature and mechanism.
• Salesforce MCP connection guide ↗ — External servers and registry.
• Salesforce MCP limitations ↗ — Transport and authorization compatibility.
• AG-UI 1.0 release ↗ — 2026 specification.
• LangGraph orchestration guide ↗ — State and human checkpoint patterns.
• Temporal Durable AI ↗ — Durable execution and approvals.