How to talk to SRE.ai
Learn how to phrase requests effectively in SRE.ai's Chat interface

SRE.ai's Chat works in two modes.
You start in free-form, describe what you're working on in your own words, no special syntax required.
From there, Chat surfaces suggested prompts as clickable options at each step, guiding you forward without requiring you to know what to type next.
The first message is yours. The path forward is offered.
This guide covers both: what to type when you're getting started, and what to expect as Chat guides you through.
How to read the transcripts in this guide
Conversations in SRE.ai involve two kinds of user input:
Typed input: you write your own message in the text field
Suggested prompt: Chat surfaces a clickable option and you select it
In the transcripts below, suggested prompts are marked like this:
Chat suggested: "Design a solution" You: Design a solution
The distinction matters because it shows when you're navigating freely and when the product is guiding you.
Starting a change

A Change is SRE.ai's unit of work.
You always start one with free-form input, describe what you're working on, and SRE.ai creates a Change to track it through the full lifecycle.
You (typed): I need to add a validation rule on the Account object that prevents saving if the Phone field is empty when the record type is Partner.
SRE.ai: Got it. I've created a Change for this.
Chat suggested: "Design a solution" · "Build directly"
After creating a Change, Chat surfaces two paths: invoking the Design Agent to produce a technical spec first, or invoking the Build Agent directly for simpler tasks.
You can click a suggestion or type your own direction, both work.
You could also type:
"Create a change for adding a validation rule to Account"
"We need a validation rule on Account — Phone required for Partner record type"
"There's a bug: Partner accounts can save without a phone number"
All three land in the same place.
The more context you include upfront (the object, the condition, the expected behavior) the less back-and-forth the agent needs before it starts.
Working with agents
Agents handle the design and implementation work.
The typical flow is: describe → design → approve → build.
Invoking the Design Agent
Chat suggested: "Design a solution" You: Design a solution
SRE.ai: Starting the Design Agent. I'll explore your repository and the Account object metadata, then produce a design document for your review.
[Agent researches repository patterns and Salesforce metadata]
SRE.ai: Design document ready. I'm proposing a standard Salesforce validation rule using an ISPICKVAL formula. The document includes success criteria, implementation steps, and a testing strategy. Ready for your review.
You don't need to click the suggestion, you can type "design a solution for...," "let's think through this first," or "create a spec for..." and the Design Agent activates. SRE.ai routes based on intent, not syntax. The suggested prompt is a shortcut, not a requirement.
Approving a design and building
After reviewing the design document, you approve it and move to implementation.
Chat suggested: "Build this" You: Build this
SRE.ai: Starting the Build Agent. I'll use the dev sandbox as the target instance — is that correct?
You (typed): Yes.
SRE.ai: Building. I'll create a feature branch, implement the validation rule, validate, and commit the result.
[Agent creates branch, implements, validates, and commits]
SRE.ai: Done. The validation rule has been implemented, validated, and committed to a feature branch. Ready to create a pull request?
The Build Agent always confirms the target instance before it starts. This is a human-in-the-loop checkpoint, you can redirect to a different org if the one it selects isn't right.
Moving a change through the pipeline
Once work is on a feature branch, Chat guides you through the commit, PR, and deployment steps.
Creating a pull request
Chat suggested: "Create a pull request" You: Create a pull request
SRE.ai: Creating a pull request in your GitHub repository, targeting the integration branch based on your pipeline configuration.
[PR created]
SRE.ai: PR created. You can review it in GitHub or from the Change detail view here.
Deploying to the next environment
Chat suggested: "Deploy to next environment" You: Deploy to next environment
SRE.ai: Before I deploy, here's what I'm seeing:
Target: Integration sandbox (next stage in your pipeline)
Quality gates: PR approval ✓ · Code coverage 82% ✓ · Static analysis ✓
Test level: Run Local Tests (pipeline default)
Confirm deployment?
Chat suggested: "Yes, deploy" You: Yes, deploy
SRE.ai: Deploying to Integration. I'll run local tests and report back.
SRE.ai always surfaces the deployment target, quality gate status, and test level before executing. This gives you one place to confirm that everything is correct, you don't need to check these separately.
Overriding the test level
If you want to run a higher test level than the pipeline default, type it rather than clicking the suggestion.
You (typed): Deploy to next environment, but run all tests this time.
SRE.ai will apply Run All Tests if your pipeline governance permits it. You can only select a level equal to or higher than the pipeline default, governance rules can't be bypassed through Chat.
Running a higher test level than the pipeline default will take longer and block the pipeline for your team during that window. SRE.ai will surface a warning before you confirm.
When something goes wrong
Deployment failure
If a deployment fails, SRE.ai surfaces the error and offers a path forward without you having to ask.
SRE.ai: Deployment to Integration failed. Here's what happened: [error summary]
Chat suggested: "Fix deployment errors"
You: Fix deployment errors
SRE.ai: Reviewing now. I'll propose a resolution before making any changes.
The "Fix deployment errors" prompt only appears when the most recent deployment has failed. If you don't see it, check the deployment status in the Change detail panel to confirm a failure occurred.
What SRE.ai needs from you
Guided prompts handle most of the navigation.
Free-form input is where context matters most, specifically when starting a change or invoking an agent.
Three things help:
The object or component. "The Account object," "the Case Type picklist," "the OpportunityLineItem trigger", naming what's involved saves a round-trip.
The condition or behavior. "When the record type is Partner," "after a successful deployment," "if the field is empty", context shapes the solution.
The intended outcome. "Should prevent saving," "should commit to the feature branch," "should run all tests", stating what you want, not just what's broken.
You don't need all three every time. Once a Change is underway, the guided prompts carry most of the work forward. Free-form input is most valuable at the start, when the agent needs to understand what it's building.
Last updated

