From AI coding agents to Agentforce

Agentic Engineering is applying software engineering discipline to AI-driven work on Salesforce. Where a proof-of-concept agent is clicked together in minutes, Agentic Engineering treats every result (an Agentforce agent, but equally an Apex class, a Flow or a headless component) as something that must be designed, version-controlled, tested, deployed and monitored, just like any other business-critical application.

In English the term is strongly claimed by Salesforce and large international system integrators, but in Dutch it is virtually unclaimed. Outbirds deliberately uses Agentic Engineering as the name for a concrete way of working, not a buzzword. The difference lies in the lifecycle: an agent or component is only engineered when it behaves predictably within defined boundaries, its behaviour is traceable, and you can safely change it without regression.

For Outbirds this is not a standalone product but one of three facets of a partnership around Salesforce. Implementation (Field Service, Service Cloud, Revenue Cloud), headless (Salesforce as an API-first backend) and agentic (AI coding agents and runtime agents) belong together. Headless is the differentiating angle, and agentic is the proof that we already do this today.

For service-intensive and asset-intensive organisations that distinction is essential. An agent that creates orders, schedules service appointments or handles customer questions on the installed base directly touches processes, data and compliance. That is no place for an experiment; that is a place for engineering.

A large part of the work happens in the IDE and the CLI, not in an agent conversation. Outbirds uses AI coding agents (Claude Code and OpenAI Codex, and more broadly MCP-compatible agents such as Cursor and Windsurf) to build Agentforce agents, Apex, Flows, Lightning components and headless integrations faster and more reliably. We call this applied agentic engineering on Salesforce: the agent runs in the tooling the developer already uses and talks to the org through the Model Context Protocol (MCP), an open standard created by Anthropic.

The technical foundation came together at TrailblazerDX 2026 (15 April 2026) under Salesforce Headless 360 and the Salesforce DX MCP Server. Headless 360 exposes the platform as APIs, MCP tools and CLI commands (over 4,000 existing APIs, more than 60 MCP tools, more than 220 CLI commands and over 30 preconfigured coding skills). The DX MCP Server (Beta) gives MCP-compatible agents structured access to query object schemas, create Apex classes, modify Flows and validation rules, create scratch orgs, run tests and deploy metadata, without leaving the IDE. Tools such as ApexGuru bring quality straight into the workflow.

There is also Agentforce Vibes, Salesforce’s own coding agent with multi-model support (including Claude Sonnet 4.5 and GPT-5), integrating with Salesforce tools such as Code Analyzer and DevOps Center. Important to remember: this deepens how you build on Salesforce. The metadata and code remain yours and remain in Salesforce; the agents are a faster, more reliable way to create them.

Agentforce is Salesforce’s AI agent platform, built natively into the platform. Because it runs on the platform, a runtime agent has direct access to your CRM data, metadata, the security model and existing automation (Flows, Apex). You build agents without first constructing a separate integration layer, and Salesforce remains the single source of truth.

The core of Agentforce is the Atlas Reasoning Engine. It works in three steps: it understands the intent and scope of a question, determines which data and actions are needed, and then executes those actions autonomously to complete the task. On a follow-up question, the agent can also explain its reasoning.

You configure an agent in Agent Builder, the visual build environment inside Salesforce. There you define the agent’s role, attach Topics, Instructions and Actions and set up grounding through Data Cloud. Outbirds sees Agentforce as the runtime engine, and Agentic Engineering as the way you build that engine into your organisation responsibly.

These three are often confused, but they differ fundamentally in autonomy.

A chatbot (like a classic Einstein Bot) follows predefined dialogues, intents and flows. It is deterministic and cannot handle questions outside the script. A copilot is a digital assistant: it helps a person within their work, but waits for instructions and does not act independently.

An AI agent behaves like a digital employee. It plans and executes multi-step actions towards a goal, makes decisions based on context and adapts during a conversation or workflow. An Agentforce agent can work customer-facing and largely autonomously, without a human steering every step.

That difference determines how you build and test. You test a chatbot on its dialogue paths. An autonomous agent must be tested on behaviour under variation, on its boundaries and on what it must not do. That is exactly why Agentic Engineering is needed once you move past the copilot stage.

The Atlas Reasoning Engine works with three building blocks that you configure in Agent Builder.

Topics are the agent’s jobs-to-be-done. Each Topic maps to a recognisable user intent, for example scheduling a service appointment or checking an order status. Atlas reads the input and selects the most relevant Topic.

Instructions belong to a Topic and are written in natural language, comparable to prompts. Together with the Topic’s scope and description they form the guardrails: they determine how the agent should deliver an outcome and what it may and may not do.

Actions are the concrete operations the agent can perform, attached to a Topic. Under the hood these are Salesforce Flows, Apex classes or integrations. Some actions retrieve data up front to support the answer; others execute an effect after the reasoning step, such as creating or updating a record.

Good Agentic Engineering starts here: sharply scoped Topics, explicit Instructions and reusable, safely designed Actions. Sloppy scoping leads to an agent that picks the wrong Topic or acts outside its mandate. These very Flows, Apex classes and metadata are often built together with AI coding agents in a sandbox or scratch org before being validated into production.

Data security has two sides, and it is important not to mix them up. The core line for both: your work environment and data, always secure and enterprise-grade.

In AI-assisted development, the AI coding agents work primarily on source code, metadata and configuration in your own environment. We work sandbox-first or scratch-first, and a scratch org by definition contains no data or metadata from your production org. Customer data therefore stays in the Salesforce org and does not go to the model. At the same time we are not naive here: the Headless 360 and MCP tools can technically also run SOQL, DML and data export against an org, and can run against production. That is why we deliberately restrict this with a least-privilege integration user, explicit org allowlisting (the –orgs flag) and selective tools (the –tools flag), so an agent cannot see or do more than strictly necessary. Salesforce provides the access layer, but not the code governance layer: your own quality gates, code review, tests and deploy gates remain necessary and are part of the Outbirds approach.

For runtime agents (Agentforce), security runs through the Einstein Trust Layer, a layer of guardrails between your data and the language model. The core: zero data retention (external model providers do not keep your data and data is deleted after the response), dynamic grounding on verifiable data from Data Cloud to limit hallucinations, data masking of sensitive fields, plus toxicity detection and audit logging. An Agentforce agent also inherits the identity, sharing rules, field-level security, permission sets, validation rules and governor limits of the org. For GDPR questions, the combination of the Salesforce security model, grounding and the Trust Layer is the technical basis, but responsible configuration remains human work.

An agent is not a one-off delivery but software with a lifecycle. Outbirds uses a repeatable approach: design, ground, test, deploy, monitor.

Design: define Topics, Instructions and Actions based on real processes and the agent’s mandate. We build the underlying Flows and Apex where possible with AI coding agents in a sandbox or scratch org.

Ground in Data Cloud: connect the agent to relevant, clean data sources so answers are factual. Data Cloud provides grounding, analytics and audit trails.

Test in the Agentforce Testing Center: validate behaviour before going to production. Note: certain features, such as Data Cloud grounding and audit logging, behave differently in a sandbox than in production, so test results must be read in context.

Deploy through DevOps: move agents, code and metadata from sandbox to production in a controlled way, with version control and deploy gates instead of manual clicking. This is where the quality gates come together that put agent output through the same review as human work.

Monitor through the Trust Layer: follow interactions, audit trails and behaviour in production and adjust.

This cycle is what separates Agentic Engineering from a quick experiment: you can keep improving an agent safely without regression.

Agentforce and Microsoft Copilot Studio solve related problems from different starting points. Agentforce is natively interwoven with the Salesforce platform: data, metadata, security and automation live in the same environment where the agent runs. For service-intensive and asset-intensive organisations that already run their customer, order and service processes on Salesforce, that means less integration work and grounding on data that already lives in the platform. Microsoft Copilot Studio is more strongly anchored in the Microsoft 365 and Azure ecosystem.

The choice therefore depends mainly on where your core data and processes already live, not on an abstract feature comparison. For organisations with the installed base, service contracts and billing on Salesforce, grounding on that data, and thus Agentforce, is the most natural fit.

Commercial models change quickly and differ per edition, region and consumption. We deliberately do not include prices that age fast. In an intake we first map your use case, data landscape and volumes, and only then the costs, so an agent has a defensible business case instead of an open end.

What is Agentic Engineering?

Agentic Engineering is the discipline of designing, building, testing, deploying and managing AI agents and headless components as production-ready software. On Salesforce this has two sides: AI coding agents such as Claude Code and OpenAI Codex that help build faster and more reliably on Salesforce DX and metadata, and runtime agents in Agentforce that are grounded in Data Cloud and secured with the Einstein Trust Layer. It deepens Salesforce, it does not replace it: Salesforce remains the core and the system of record.

How does Outbirds use Claude Code and Codex in Salesforce development?

Outbirds uses MCP-compatible AI coding agents such as Claude Code, OpenAI Codex, Cursor and Windsurf to build Agentforce agents, Apex, Flows, Lightning components and headless integrations. Through the Salesforce DX MCP Server and Headless 360, the agents query object schemas, write and modify code and metadata, run tests and deploy, in your own environment. We work sandbox-first or scratch-first, with a least-privilege integration user, org allowlisting (–orgs) and selective tools (–tools).

Is Agentforce safe with our data and GDPR?

Runtime agents in Agentforce are secured through the Einstein Trust Layer: zero data retention (external models do not keep your data), dynamic grounding on verifiable data from Data Cloud to limit hallucinations, data masking, toxicity detection and audit logging. The agent inherits the identity, sharing rules, field-level security and governor limits of the org. Combined with the Salesforce security model, this forms the technical basis for GDPR-compliant work, although proper configuration and data classification remain human work.

Does our customer data go to the AI model when you build with AI coding agents?

No, that is not the intention and we set it up accordingly. The AI coding agents work primarily on source code, metadata and configuration, and we work sandbox-first or scratch-first, where a scratch org by definition contains no production data or metadata. Customer data stays in the Salesforce org. At the same time, the Headless 360 and MCP tools can technically run SOQL, DML and exports against production, so we deliberately restrict that with a least-privilege integration user, org allowlisting and selective tools, plus our own quality gates and review.

What is the Atlas Reasoning Engine?

The Atlas Reasoning Engine is the reasoning heart of Agentforce. It first understands the intent and scope of a question, determines which data and actions are needed, and then executes those actions autonomously. It works with Topics (the jobs-to-be-done), Instructions (guardrails in natural language) and Actions (the concrete operations, backed by Flows, Apex or integrations).

How do you build and manage an AI agent in Salesforce?

Through a repeatable lifecycle: design (Topics, Instructions and Actions in Agent Builder, with the underlying Flows and Apex often built with AI coding agents in a sandbox or scratch org), ground in Data Cloud on clean data, test in the Agentforce Testing Center, deploy from sandbox to production through a DevOps process with version control and deploy gates, and monitor through the Trust Layer. This cycle makes it possible to keep improving an agent safely without regression.

Does agentic or headless Salesforce replace our existing platform?

No. Headless and agentic are ways to use Salesforce more deeply, not replacements. Your data model, automation, security and governance stay in Salesforce, which remains the single source of truth. AI coding agents build on your own metadata and code, and runtime agents in Agentforce run on the platform with the existing sharing rules and the Einstein Trust Layer.