> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/mcp-and-ai-reference/build-with-an-ai-assistant.md).

# Build with an AI assistant

Start with the service you want to deliver, then let your assistant inspect the available integrations, inputs and execution options. A useful result is a tested automation with a clear outcome, not only a generated flow.

This guide describes the general authoring lifecycle. The connection reviewed on 21 October 2026 advertises authoring, Service and deployment tools. Availability and permissions remain connection-specific. For a complete Service plan using existing apps, triggers, Work Items and typed bindings, follow [Build a service with an AI assistant](https://docs.autommate.com/userguide/mcp-and-ai-reference/structured-service-authoring).

## Check capabilities first

Before changing anything, establish the environment, selected tenant, product version and signed-in account. Inspect the tools advertised by that connection and their current input schemas. Capabilities can depend on the server version, license and account permissions.

| Check                                         | Evidence to use                                                | If it is unavailable                                                             |
| --------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Find integrations and actions                 | Library and action search results                              | Report the missing integration or restricted search scope.                       |
| Inspect a runnable automation                 | Its current metadata and input contract                        | Ask for the missing information; do not infer inputs from its name.              |
| Create or edit a flow, app, action or service | A tool advertised by this connection, with the required schema | Prepare a design and complete the build through the supported product interface. |
| Validate or test a proposed change            | A supported validation or test operation and its result        | Use the documented product test procedure and record what remains untested.      |
| Publish or deploy                             | A supported operation and permission for the target scope      | Hand the reviewed change to an authorized operator.                              |
| Confirm an execution                          | A matching run and the expected target-system result           | Keep the outcome unconfirmed until both can be checked.                          |

A capability described in documentation is not proof that it is enabled on the current connection. Refresh discovery after reconnecting or changing tenant. Use IDs and references returned by the current connection; do not copy them from an example or another tenant.

## Follow the lifecycle

```mermaid
flowchart TB
    A[Discover] --> B[Inspect]
    B --> C[Create or edit]
    C --> D[Validate and test]
    D --> E{Meets acceptance criteria?}
    E -->|No| F[Fix]
    F --> D
    E -->|Yes| G[Review and approve]
    G --> H[Publish or deploy]
    H --> I[Monitor and verify]
```

### 1. Describe the outcome

Give the assistant the starting event, source and destination systems, required output and boundaries. Include what should happen when data is incomplete or an external system fails.

For example:

> When a Jira issue matches our agreed service category, create one linked request in Xurrent with the approved field mapping. Check for an existing target request before creating one. Verify the result and report a clear failure if the request cannot be created.

### 2. Discover what already exists

Use `libraries_search` to browse integrations and `library_search_actions` to find candidate actions. Inspect each selected action with `library_get_action`. Search existing automations with `automs_search` before proposing a replacement or duplicate.

Resolve names to the returned references. A search restricted to objects created by the current user is not a complete inventory of the tenant.

### 3. Inspect the contract

Read the inputs, outputs, trigger type and dependencies needed for the chosen path. For an existing automation, use `automs_get`; request `include_flow: true` when you need its explanation or diagram. This returns a flow description, not editable raw flow JSON.

Confirm required field mappings and credential references. `credentials_search` identifies stored connections; an active flag does not test the external connection. Resolve values from verified task context, declared runtime inputs, earlier outputs or an authorized native lookup. Ask the owner only for unresolved values or decisions. Follow [deployment input resolution](https://docs.autommate.com/userguide/mcp-and-ai-reference/deployment-input-resolution) instead of presenting every required input as a new question.

### 4. Create or edit a draft

For Hyperflows and Work Items, use `automs_create`, `automs_set_variables`, `automs_get_flow` and `automs_edit_flow` according to the active schemas. Preserve the expected revision when editing. For Services, preview `services_create` before apply: the reviewed create operation publishes the initial blueprint version 1.0.0 when applied. Do not describe that apply as draft-only. Preparing a deployment draft and making it live are separate operations.

Keep the trigger, actions, data mappings, error path and output contract explicit. Preserve identifiers required by an existing object or by its logs and dependencies. Do not invent a JSON format or remove unfamiliar fields merely to simplify the structure.

### 5. Validate, test and fix

Validate the draft using the operations supported by the installed version. Then run the agreed test cases with test data and authorized connections. A successful structural check does not prove that an API call, credential or business outcome works.

For each case, record the input, expected result, observed result and evidence. Fix the specific failure, then repeat the affected test. Include duplicate input, missing fields and an external failure where these matter to the service.

### 6. Review, approve and publish

Present the proposed change, target tenant, connections, test results and remaining gaps to the responsible operator. Obtain the required approval before enabling the trigger or publishing a change that affects real systems.

After publishing or deploying, read back the target object and version. Confirm that the intended configuration is active in the intended tenant. A saved draft or successful publish response alone does not prove execution.

### 7. Monitor the outcome

For a supported existing Autom, read its input contract before calling `automs_run` and confirm the intended real execution. Use a fresh idempotency key for that execution; an exact retry with the same key and arguments replays the first outcome according to the current declaration. This protection does not establish end-to-end idempotency of the business service.

Use `runs_search`, `runs_get` and `runs_get_latest_error` to inspect the relevant execution. If a webhook start does not return an operation ID, locate the matching run rather than starting another one. Check the target-system record or result as well as the platform status.

Report what was created or changed, where it ran, the resulting record or output, and any remaining limitation.

## Separate building a service from using it

An author changes the service definition. A consumer submits a request to an approved deployment. Keep these roles separate in the design and in the permissions you configure.

| Role                                | Purpose                                                      | Boundary to establish                                                     |
| ----------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------- |
| Service author                      | Define actions, inputs, error handling and reusable behavior | Authoring permissions, draft ownership and review process.                |
| Deployment operator                 | Bind the definition to a target tenant and its connections   | Deployment scope, version and tenant-specific configuration.              |
| Service consumer or consuming agent | Request an allowed business outcome                          | Approved inputs and the selected deployment; no assumed design authority. |

Authentication to MCP establishes access to Autom Mate. Access to Jira, Xurrent or another application uses the relevant application connection. Keep those credentials in the supported connection mechanism, not in prompts or shared service examples.

Do not assume that selecting one tenant grants access to other tenants or permits bulk deployment. Check the supported scope for each operation.

## A useful completion report

Use a short report that a person or another agent can act on:

| Field                  | Record                                                       |
| ---------------------- | ------------------------------------------------------------ |
| Environment and tenant | The actual target used.                                      |
| Definition and version | The saved or deployed object that was read back.             |
| State                  | Designed, drafted, validated, tested, published or executed. |
| Outcome                | Expected result and observed result.                         |
| Evidence               | Run reference and target-system record, when available.      |
| Next step              | One concrete unresolved item, owner and required action.     |

Keep these states distinct. “Draft created,” “test passed” and “customer request completed” describe different results.

## Related guides

* [Documentation scope and product versions](https://docs.autommate.com/userguide/start-here/documentation-scope-and-product-versions)
* [For AI agents: read this first](https://docs.autommate.com/userguide/mcp-and-ai-reference/for-ai-agents-read-this-first)
* [Discovery tool contracts](https://docs.autommate.com/userguide/mcp-and-ai-reference/discovery-tool-contracts)
* [Inspection tool contracts](https://docs.autommate.com/userguide/mcp-and-ai-reference/inspection-tool-contracts)
* [Run an existing Hyperflow through MCP](https://docs.autommate.com/userguide/mcp-and-ai-reference/run-an-existing-autom-through-mcp)
* [Track run status and verify results](https://docs.autommate.com/userguide/mcp-and-ai-reference/track-run-status-and-verify-results)