user-robotAgents

Learn about SRE.ai's agentic capabilities

SRE.ai Agents

Overview

Agents are AI-driven capabilities that execute complex Salesforce development tasks through natural language.

circle-check

Each agent is powered by a specialized LLM trained on Salesforce development patterns, best practices, and platform-specific constraints.

Agents understand Salesforce metadata structures, Apex conventions, deployment requirements, and organizational patterns in your repository.

Agents keep users in control. Every step an agent takes is visible, every artifact it produces is presented for review, and users can intervene at key decision points before work proceeds.


How Agents work

Activation

Agents are invoked through the chat interface based on intent.

circle-check

Examples:

  • "I need to implement a regression test class for the Case Type picklist" → Design Agent

  • "Let's build this" (after a design is approved) → Build Agent

  • "Deploy these changes to staging" → Deploy Agent

Visibility

Agents surface every action they take. When an agent executes, users see:

  • Thought process: The agent's reasoning as it plans the work

  • Plan: A structured list of steps the agent will execute

  • Step-by-step progress: Each action logged with timestamps

  • Artifacts: Design documents, code files, PRs, and other outputs

Users can expand any step to see details, including commands run, files read, and web searches performed.

Human-in-the-loop

Agents pause at key decision points for user input:

  • Design documents require approval before building begins

  • Generated code is presented for review before committing

  • Deployments surface what will change before executing

This ensures users maintain control over what gets created and deployed.

Integration with Changes

Agent work ties back to SRE.ai's Changes feature. When an agent begins work, it creates or links to a Change artifact that tracks the full lifecycle, from design through deployment. This provides a single view of everything associated with a feature or fix.

Agents can also link to external issue trackers. If a Jira ticket is referenced, the agent associates its work with that issue. However, linked tickets are not required. Users can simply describe what they need.


Design agent

The Design Agent creates technical design documents for Salesforce development work.

What it does

Given a problem statement or feature request, the Design Agent:

  • Explores your repository structure and existing patterns

  • Examines relevant Salesforce metadata (objects, fields, picklists, etc.)

  • Research best practices and validation requirements

  • Designs a solution architecture

  • Produces a comprehensive technical design document

Output

The Design Agent generates a design document that includes:

  • Success criteria: What the implementation must achieve

  • Architecture: Component overview and relationships

  • Design decisions: Rationale for the chosen approach

  • Implementation plan: Steps to build the solution

  • Testing strategy: How the solution will be validated

  • Risks: Potential issues and mitigations

Design documents are stored in the Change artifact and can be approved, revised, or rejected before building begins.

Example

User: "Implement a regression test class for the value in Type picklist"

Design Agent actions:

  1. Confirms the issue and creates a Change

  2. Explores repository structure and patterns

  3. Examines the Case object and the Type picklist metadata

  4. Research picklist validation best practices

  5. Designs the test architecture

  6. Creates a comprehensive technical design document

  7. Submits design for approval

Output: A design document specifying that the solution will use Salesforce's Schema API to dynamically retrieve and validate picklist metadata, with success criteria including 100% code coverage and immediate failure when required values are missing.

Steps

  1. Describe the problem or feature in the chat interface

  2. The Design Agent confirms the issue and creates a linked Change

  3. Review the agent's plan via "View Plan"

  4. Monitor progress as the agent researches and designs

  5. Review the generated design document

  6. Approve the design to proceed to building, or request revisions


Build agent

The Build Agent implements solutions based on approved designs or direct instructions.

What it does

Given an approved design or a build request, the Build Agent:

  • Initializes the repository context

  • Creates a feature branch from main

  • Generates code files following your repository's patterns

  • Creates associated metadata files

  • Deploys and validates in a target instance

  • Commits and pushes changes

Output

The Build Agent produces:

  • Feature branch: A new branch for the implementation

  • Code files: Apex classes, Lightning components, or other artifacts

  • Metadata files: Associated .meta.xml files configured correctly

  • Validation results: Confirmation that code deploys and tests pass

  • Committed changes: Code pushed to the feature branch

All generated code follows existing repository patterns. The agent examines your codebase to match naming conventions, file organization, and coding style.

Example

User: "Let's build this" (after approving a design for a regression test class)

Build Agent actions:

  1. Confirms target instance (e.g., poolorg01)

  2. Implements solution per the design document

  3. Creates feature branch (e.g., feature/d9c96ea9) from main

  4. Creates CaseTypePicklistTest.cls file

  5. Creates CaseTypePicklistTest.cls-meta.xml file

  6. Deploys and validates test class

  7. Commits and pushes changes

Output: A complete, validated implementation on a feature branch ready for review.

Steps

  1. Approve a design document, or describe what you want built directly

  2. The Build Agent confirms the target instance

  3. Review the agent's plan via "View Plan"

  4. Monitor progress as the agent creates and validates code

  5. Review the generated files and validation results

  6. Proceed to PR creation or request changes


Deploy agent

The Deploy Agent handles AI-driven deployments to target environments.

What it does

Given a deployment request, the Deploy Agent:

  • Identifies what needs to be deployed

  • Confirms the target environment

  • Executes the deployment with appropriate validations

  • Reports results and surfaces any issues

Output

The Deploy Agent produces:

  • Deployment confirmation: What was deployed and where

  • Validation results: Test execution and quality gate status

  • Error reporting: Clear surfacing of any failures with context

Example

User: "Deploy these changes to staging"

Deploy Agent actions:

  1. Identifies the changes to deploy

  2. Confirms staging as the target environment

  3. Executes deployment

  4. Runs associated validations

  5. Reports success or surfaces issues

Output: Deployed changes with validation results, logged in the Change timeline.

Steps

  1. Describe what you want deployed and where

  2. The Deploy Agent confirms the target and scope

  3. Review the deployment plan

  4. Monitor progress as the agent deploys and validates

  5. Review results in the Command Center


Best practices

Start with the design for complex work.

For anything beyond simple changes, let the Design Agent create a technical design first. This ensures alignment before code is written and creates documentation for future reference.

Review plans before execution.

Use "View Plan" to understand what the agent intends to do. This is your opportunity to catch misunderstandings before work begins.

Link to issue trackers when available.

While not required, linking to Jira or other issue trackers creates traceability and keeps project management in sync with actual development.

Use agents iteratively.

Agents work well in conversation. If the first output isn't quite right, provide feedback and let the agent refine its approach.

Trust but verify.

Agents are designed to keep you in control. Review generated designs, inspect created code, and validate deployments. The visibility is there for a reason.

Last updated