Skip to content
Workflow templates

See governed agents work end to end.

Each template shows what starts the work, what the agent does, where a person decides, the controls Alyria applies and the shared knowledge the agent uses.

Software development

  • Brief to pull request

    An agent turns an agreed brief into a proposed change that is ready for review.

    Starts when
    A ticket in Jira or Linear is marked ready with an agreed brief.
    The agent
    1. Reads the brief, the relevant code and the team's architecture guidance.
    2. Plans the change and implements it on its own branch.
    3. Runs the project's existing checks and fixes what it broke.
    4. Opens a GitHub pull request that explains the change and links the brief.
    A person decides
    A reviewer approves the pull request. Branch protection still applies to the agent.
    Controls
    • Repository, branch and tool access scoped to this task.
    • No merge or deploy without the required approval.
    • Secrets the agent encounters cannot be sent to outside destinations.
    Shared knowledge
    Team architecture guidance and approved incident lessons.
    Result
    A reviewable change with its reasoning and checks attached.
  • Agent code review

    Every eligible revision gets an agent review with findings the author can act on.

    Starts when
    A pull request is opened or updated on GitHub.
    The agent
    1. Reads the diff and the code around it.
    2. Checks the change against the brief, team conventions and known failure patterns.
    3. Posts findings with locations and suggested fixes.
    4. Re-reviews when the author pushes a new revision.
    A person decides
    People decide which findings to accept and who approves the merge.
    Controls
    • Read access to the repository; comment-only write access.
    • Cannot approve or merge its own or another agent's change.
    Shared knowledge
    Team review conventions and approved lessons from past incidents.
    Result
    Faster reviews with consistent findings on every revision.
  • Behavior verification

    An agent exercises the changed behavior the way a user would and reports what happened.

    Starts when
    A change is deployed to a test environment; results are posted to the GitHub pull request and Slack.
    The agent
    1. Works out which user journeys the change affects.
    2. Runs those journeys against the test environment.
    3. Captures results, screenshots and logs as evidence.
    4. Reports pass or fail with the evidence attached to the change.
    A person decides
    The reviewer uses the evidence when deciding whether to approve.
    Controls
    • Test environment only; no access to production data.
    • Test credentials scoped to the verification run.
    Shared knowledge
    Product test guidance and known user journeys.
    Result
    Evidence that the change works as a user would experience it.
  • Request to requisition

    An agent turns an incomplete buying request into a requisition ready for approval.

    Starts when
    An employee submits a buying request.
    The agent
    1. Identifies missing details such as quantity, cost center and delivery date.
    2. Asks the requester for what it cannot find in permitted records.
    3. Matches the request to approved suppliers and catalog items.
    4. Prepares the requisition on the right purchasing route.
    A person decides
    The budget owner approves the requisition before it becomes an order.
    Controls
    • Approved suppliers, categories and budgets enforced.
    • Cannot place orders or commit spend.
    Shared knowledge
    Approved contract terms from Legal and budget guidance from Finance.
    Result
    Complete requisitions that reach the right approver the first time.
  • Quote comparison

    An agent reconciles supplier quotes and prepares a recommendation for the buyer.

    Starts when
    Two or more supplier quotes arrive for the same request.
    The agent
    1. Normalizes price, terms, delivery and quantity across the quotes.
    2. Flags differences and anything that conflicts with approved contract terms.
    3. Checks the totals against budget and earlier related purchases.
    4. Prepares a recommendation with the comparison attached.
    A person decides
    A buyer chooses the supplier and approves any exception to standard terms.
    Controls
    • Cumulative spend checked across related purchases.
    • Supplier data shared only with approved systems.
    Shared knowledge
    Approved contract terms and current budget guidance.
    Result
    A clear, evidenced recommendation instead of a spreadsheet hunt.
  • Supplier follow-up

    An agent tracks missing supplier information and follows up until it is complete or escalated.

    Starts when
    A supplier packet is missing required documents or details.
    The agent
    1. Lists what is missing against the onboarding requirements.
    2. Sends follow-ups to the supplier contact within its permitted scope.
    3. Updates the record as documents arrive.
    4. Escalates gaps it cannot close to the coordinator.
    A person decides
    Changes to supplier bank details need independent verification and a named approver.
    Controls
    • Changed supplier details are verified independently before use.
    • Contact limited to the supplier's registered contacts.
    Shared knowledge
    Supplier onboarding requirements and approved message templates.
    Result
    Supplier records that are complete before anyone needs them.
  • Alert to evidenced case

    An agent investigates an alert and prepares a case an analyst can act on.

    Starts when
    A detection fires in your security tooling and is posted to the team's Slack channel.
    The agent
    1. Gathers permitted context about the user, host and related activity.
    2. Investigates related signals across approved tools.
    3. Assesses whether the alert is worth escalating.
    4. Prepares a case with the evidence and its reasoning.
    A person decides
    An analyst decides whether to escalate and what happens next.
    Controls
    • Read-only access to the tools needed for investigation.
    • Case evidence stays within its permitted audience.
    Shared knowledge
    Approved incident runbooks and authorized asset context.
    Result
    Analysts start from an evidenced case, not a raw alert.
  • Incident scoping

    An agent follows leads across tools to find other systems involved in an incident.

    Starts when
    An analyst opens an incident ticket in Jira.
    The agent
    1. Starts from the known indicators in the case.
    2. Follows relevant, permitted leads across logs and tools.
    3. Adds affected systems and accounts to the incident scope.
    4. Summarizes what changed in the scope and why.
    A person decides
    The incident lead confirms the scope before response begins.
    Controls
    • Investigation access scoped to the incident and time-limited.
    • No response actions during scoping.
    Shared knowledge
    Asset ownership and dependency context from Engineering.
    Result
    A current, evidenced incident scope for the response team.
  • Containment proposal

    An agent prepares the next containment decision with its impact and recovery plan.

    Starts when
    The incident lead asks for a containment option.
    The agent
    1. Lists candidate targets such as hosts, accounts or network paths.
    2. Checks dependencies and business impact for each target.
    3. Drafts a scoped proposal with a recovery plan.
    4. Submits it for the required authorization.
    A person decides
    An authorized responder approves before any disruptive action runs.
    Controls
    • Response authority separate from investigation access.
    • Authority rechecked against current incident state before action.
    Shared knowledge
    Approved response playbooks and asset dependency context.
    Result
    Faster, better-scoped containment decisions.

Financial operations

  • Invoice exception resolution

    An agent investigates an invoice that does not match its records and routes a resolution.

    Starts when
    An invoice fails matching against its order or receipt.
    The agent
    1. Compares the invoice with the order, receipt and contract terms.
    2. Finds the cause of the mismatch in related records.
    3. Drafts a supported resolution with the evidence.
    4. Routes it to the right reviewer.
    A person decides
    A finance reviewer approves the resolution before payment.
    Controls
    • Cannot approve, post or pay its own proposed resolution.
    • Changed payment details are rechecked before payment.
    Shared knowledge
    Approved purchasing terms and accounting guidance.
    Result
    Exceptions resolved with evidence instead of email threads.
  • Reconciliation investigation

    An agent traces a difference between the subledger and general ledger.

    Starts when
    A reconciliation shows an unexplained difference.
    The agent
    1. Traces the difference to the transactions behind it.
    2. Identifies timing, mapping or posting causes.
    3. Prepares evidence for a proposed resolution.
    4. Routes the proposal to the accountant who owns the account.
    A person decides
    The account owner approves any adjusting entry.
    Controls
    • Read access to the relevant ledgers only.
    • Preparation and posting authority kept separate.
    Shared knowledge
    Accounting guidance and the entity's own close procedures.
    Result
    Differences explained with evidence before close.
  • Close readiness

    An agent keeps the close moving by tracking dependencies, evidence and approvals.

    Starts when
    The close calendar opens; status updates go to the finance channel in Slack.
    The agent
    1. Checks each close task's dependencies and status.
    2. Identifies missing evidence and approvals.
    3. Routes gaps to their owners with what is needed.
    4. Updates readiness as work completes.
    A person decides
    Controllers sign off each close step.
    Controls
    • No authority to sign off or post on behalf of an owner.
    • Data from other entities stays within its permitted audience.
    Shared knowledge
    Close procedures and current accounting guidance.
    Result
    A close that shows what is blocking it, as it happens.
  • Case intake

    An agent completes an incomplete customer request before anyone works on it.

    Starts when
    A customer request arrives in Zendesk without enough information.
    The agent
    1. Checks permitted records for this customer.
    2. Asks the customer for the facts that are missing.
    3. Classifies the request and its urgency.
    4. Updates the case so it is ready to work.
    A person decides
    Sensitive account requests wait for identity verification.
    Controls
    • Access limited to the current customer's records.
    • Customer data shared only with approved systems.
    Shared knowledge
    Approved help content and customer-facing policy wording.
    Result
    Cases that are ready to work when they reach a person or agent.
  • Guided diagnosis

    An agent works a customer problem through approved checks to a useful next step.

    Starts when
    A case in Zendesk is ready for diagnosis, with approved workarounds kept in Notion.
    The agent
    1. Selects the approved checks for the reported symptoms.
    2. Runs the checks and reads their results.
    3. Resolves the issue or prepares an escalation with the findings.
    4. Explains the outcome to the customer.
    A person decides
    Refunds and account changes above set limits need a person's approval.
    Controls
    • Verification required before account changes.
    • Refund limits checked against earlier refunds on the account.
    Shared knowledge
    Approved Engineering workarounds and Legal's customer-facing policy wording.
    Result
    More issues resolved at first contact, with clean escalations for the rest.
  • Case follow-through

    An agent keeps cases moving after the first response.

    Starts when
    A case in Zendesk is waiting on the customer or on internal work.
    The agent
    1. Checks for customer replies and outstanding internal tasks.
    2. Follows up with the customer or the owning team.
    3. Closes the case when the issue is confirmed resolved.
    4. Escalates cases that are stuck.
    A person decides
    Reopening disputes or compensation requests go to a person.
    Controls
    • Actions limited to the cases it is assigned.
    • Case history checked before each follow-up.
    Shared knowledge
    Approved follow-up templates and service policies.
    Result
    Fewer cases that stall after the first reply.