# How Trelium Works (/how-trelium-works)







These docs use eight stages as a teaching model for how an agent finishes a job. Something signals that there's work to do, the agent collects the information it needs, follows its set steps, uses AI to make sense of anything messy, checks the result against your rules, asks a person when needed, enters the result into your systems, and keeps a record. A real agent does not have to follow every stage in this order, or only once. In the product, steps have action names rather than these eight labels.

<Mermaid
  chart="`
flowchart LR
A[1. Trigger] --> B[2. Gather<br/>context] --> C[3. Execute<br/>steps] --> D[4. Reason] --> E{5. Validate} -->|Passes| G[7. Update<br/>systems] --> H[8. Log]
E -->|Needs a person| F[6. Human<br/>review] -->|Approved| G
classDef ai stroke:#7c3aed,stroke-width:3px
classDef person stroke:#d97706,stroke-width:3px
class D ai
class F person
`"
/>

In this model, the purple stage is where AI does the reading and interpreting, and the orange stage is where a person steps in (only some runs take that path). Fixed rules and lookups sit in the other stages. The diagram shows the simplest path. A real workflow can use a stage more than once or in a different order, as the [example](#example-checking-whether-a-company-is-a-good-fit) at the end of this page shows.

Each time an agent goes through these stages, that's called a **run**. A run can handle a single piece of work, such as one customer email, or several at once, and each run is one row in the agent's [Activity log](/concepts/logs-and-audit-trails).

## The eight stages [#the-eight-stages]

<Steps>
  <Step>
    ### 1. Trigger: something starts the job [#1-trigger-something-starts-the-job]

    Every run starts with a trigger. It can be an event, like a customer email arriving in an inbox, a webhook or integration event, someone starting a job by hand, or a schedule, like a check every morning at 8. The trigger also hands the agent the item it needs to work on, such as the email, its attachment, a form, or a request. See [Triggers & Inputs](/concepts/triggers-and-inputs).
  </Step>

  <Step>
    ### 2. Gather context: collect the facts [#2-gather-context-collect-the-facts]

    Before doing anything, the agent gathers the information it needs to understand the job. That can mean looking up the customer, finding the order the email refers to, or checking current stock, prices, or order status. It reads this from your actual systems at the moment of the run, so it works from today's numbers rather than an old copy.
  </Step>

  <Step>
    ### 3. Execute steps: follow the set procedure [#3-execute-steps-follow-the-set-procedure]

    The workflow runs its steps in a fixed order, like working through a checklist. The same input always takes the same path, which is what makes the agent predictable. (Technical teams call these **deterministic** steps.) A step might read from a system, look something up in a supplier's website, apply a rule, or prepare a record.
  </Step>

  <Step>
    ### 4. Reason: make sense of anything messy [#4-reason-make-sense-of-anything-messy]

    AI handles the parts that need interpretation, such as pulling line items out of a PDF, working out which order an email is about, or deciding whether a request has everything it needs. What AI produces is a draft, not a final decision. It does not get to decide on its own what goes into your systems.
  </Step>

  <Step>
    ### 5. Validate: check before acting [#5-validate-check-before-acting]

    Before anything is entered, the agent checks the draft against your business rules. Does this product exist? Does the price match what was agreed with this customer? Is the quantity within the limits your team set? When a check fails, the agent doesn't quietly carry on. It flags the problem as an **exception** and sends it to the next stage. See [Validation & Exceptions](/concepts/validation-and-exceptions).
  </Step>

  <Step>
    ### 6. Human review if needed: a person makes the call [#6-human-review-if-needed-a-person-makes-the-call]

    A person reviews the cases that need judgment. These include unclear requests, failed checks, and anything that affects money, promises to customers, or inventory. The reviewer sees what the agent proposes and why it was flagged, so they don't have to start from scratch. Routine cases that pass every check can go through without review. Your team defines which cases need a person when you build the workflow, with help from the Trelium team. See [Human in the Loop](/concepts/human-in-the-loop).

    <figure style="{ maxWidth: &#x22;48rem&#x22;, margin: &#x22;1.5rem auto&#x22; }">
            <img
              alt="A Slack message from Trelium flagging an invoice for review because the PDF
      couldn't be read, with Approve, Reject, and Ask Supplier
      buttons."
              src="__img0"
            />

      <figcaption style="{ fontSize: &#x22;0.875rem&#x22;, opacity: 0.8, marginTop: &#x22;0.5rem&#x22; }">
        A review request in Slack. The agent couldn't read the invoice PDF, so
        instead of guessing it explains why and lets a person approve, reject, or
        ask the supplier.
      </figcaption>
    </figure>
  </Step>

  <Step>
    ### 7. Update systems: enter the result [#7-update-systems-enter-the-result]

    Once the result has passed its checks, and been approved if approval is required, the agent enters it into the right system. That might be a new order in your order system, a note on a support ticket, a drafted reply, or an entry in your accounting software. If the system offers a built-in connection for other software (an API), the agent can use it. If it doesn't, the agent can work in the system through a web browser. See [Integrations](/concepts/integrations).
  </Step>

  <Step>
    ### 8. Log: keep a record [#8-log-keep-a-record]

    Every run is recorded, including the steps the agent took, when each step ran, and how the run turned out. Your team can look back at any job and see what the agent did. To judge why it went that way, compare the run with the workflow's rules and the original request. See [Logs & Audit Trails](/concepts/logs-and-audit-trails).

    <figure style="{ maxWidth: &#x22;36rem&#x22;, margin: &#x22;1.5rem auto&#x22; }">
            <img
              alt="The Activity log of an example Trelium agent. Each run shows whether it is
      running or completed, which apps it used, how many credits it used, when it
      started, and how long it took. One run is expanded to show each step with its
      time and duration."
              src="__img1"
            />

      <figcaption style="{ fontSize: &#x22;0.875rem&#x22;, opacity: 0.8, marginTop: &#x22;0.5rem&#x22; }">
        An agent's Activity log. Each row is one run, showing its status, the apps
        it used, the credits it used, when it started, and how long it took.
        Expanding a run lists every step it took, with the time of each step and how
        long it lasted.
      </figcaption>
    </figure>
  </Step>
</Steps>

## Why Trelium uses both fixed steps and AI [#why-trelium-uses-both-fixed-steps-and-ai]

Fixed steps and AI are good at different things, so Trelium uses each one where it fits.

|                        | Fixed steps                                                  | AI                                                                                                                                |
| ---------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| Good at                | Looking things up, applying rules, doing math, entering data | Reading emails and documents that are written in many different ways, matching them to the right records, spotting what's missing |
| How it behaves         | Does exactly the same thing every time                       | Adapts to different wording and formats                                                                                           |
| What keeps it in check | Your business rules                                          | Your business rules, plus a person when needed                                                                                    |

AI is very good at reading a customer's messy email, but like a person, it can occasionally misread something. That's why Trelium keeps AI to the reading and interpreting, and lets fixed rules decide what actually happens.

<Callout title="Why the split matters">
  AI can read a messy email. It cannot skip a rule.
</Callout>

## Example: checking whether a company is a good fit [#example-checking-whether-a-company-is-a-good-fit]

A sales team wants a quick answer to "is this company worth pursuing?" without researching it by hand. Their Trelium agent takes a company name posted in a team Slack channel and replies in the same thread with a verdict and any matching job postings. The same agent is shown on [What is Trelium?](/what-is-trelium).

Real workflows don't always run the eight stages exactly once, in order. This agent uses AI to read the request before it looks anything up, and uses AI again later to read job postings, so "Reason" appears twice below.

<Steps>
  <Step>
    ### Trigger [#trigger]

    Someone posts a request in a team Slack channel asking whether a specific company fits the team's ideal customer profile. The agent acts only on requests like this.
  </Step>

  <Step>
    ### Reason: read the request [#reason-read-the-request]

    The agent works out which company or companies the message is about, including when one message names several. If it already asked "which one did you mean?" or asked for a website, it reads the person's reply in the thread to work out which company or website they meant.
  </Step>

  <Step>
    ### Gather context [#gather-context]

    It looks the company up in Apollo, a company database, to find its profile, industry codes, website, and revenue.
  </Step>

  <Step>
    ### Human review: ask instead of guessing [#human-review-ask-instead-of-guessing]

    If Apollo finds no match, or several, the agent asks for clarification in the Slack thread instead of picking one. Here the person is not approving a result. They are giving the agent the missing information it needs, and the run continues from their answer.
  </Step>

  <Step>
    ### Validate: check against the profile [#validate-check-against-the-profile]

    The agent compares the company's industry classification with the team's ideal customer profile, which is the rule that decides whether the company is a fit.
  </Step>

  <Step>
    ### Execute steps: find open job postings [#execute-steps-find-open-job-postings]

    It searches Apollo for the company's open job postings and fetches the full text of each one.
  </Step>

  <Step>
    ### Reason: read each posting [#reason-read-each-posting]

    The agent reads each posting to confirm it describes genuine office-based process work, such as order entry, purchasing, accounting, sales support, or customer service. It leaves out roles like warehouse, driving, or in-person retail.
  </Step>

  <Step>
    ### Update systems: reply in the thread [#update-systems-reply-in-the-thread]

    It replies in the original Slack thread with the verdict and any matching job postings. If the check fails, the reply says so instead.
  </Step>

  <Step>
    ### Log [#log]

    The run appears in the agent's Activity log, with each step it took.
  </Step>
</Steps>

## Where to go next [#where-to-go-next]

<Cards>
  <Card title="What is Trelium?" href="/what-is-trelium">
    The short version.
  </Card>

  <Card title="Agents & Workflows" href="/concepts/agents-and-workflows">
    How a workflow is put together.
  </Card>

  <Card title="Validation & Exceptions" href="/concepts/validation-and-exceptions">
    What happens when a check fails.
  </Card>

  <Card title="Integrations" href="/concepts/integrations">
    How agents connect to your software.
  </Card>
</Cards>
