> ## Documentation Index
> Fetch the complete documentation index at: https://olyrosstudios.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Works with your stack

> Olyros Code agents show up in GitHub, Jira, and Slack — the tools your team already uses. No new dashboard to babysit.

## No new dashboard to babysit

Adoption fails when it asks people to change where they work. So Olyros Code agents meet your team inside the tools they already open every day. An engineer labels a GitHub issue and an agent picks it up. A product manager files a Jira ticket and gets the result back as a comment. A non-technical teammate asks a question in Slack and gets an answer with sources.

You manage agents from one cloud console. Your team never has to leave their workflow to use them.

## GitHub

Connect your organization with a one-click GitHub App install — no personal access tokens to mint or rotate.

<CardGroup cols={2}>
  <Card title="Per-repository access" icon="folder-tree">
    Grant each connection none, read-only, or read-write access on a per-repository basis. Read-only access is enforced at the container level, not just in application logic.
  </Card>

  <Card title="Agents with their own identity" icon="code-branch">
    Agents commit and open pull requests under their own git identity, so authorship and history are always clear in your review flow.
  </Card>

  <Card title="Hand off by label" icon="tag">
    Label any issue `agent:<name>` to hand it to that agent. It gets a scoped repository checkout, does the work, and opens a pull request for your team to review.
  </Card>

  <Card title="Short-lived credentials" icon="key">
    Agents receive minimally-scoped, short-lived repository tokens for just the task at hand — never written to disk.
  </Card>
</CardGroup>

## Jira Cloud

Connect Jira Cloud over OAuth and drive agent work straight from your board.

<Steps>
  <Step title="Label the ticket">
    Add the `agent:<name>` label to a Jira ticket to turn it into an agent task.
  </Step>

  <Step title="The agent does the work">
    The agent picks up the ticket, works in an isolated environment next to your code, and opens a pull request where relevant.
  </Step>

  <Step title="Results come back on the ticket">
    Outcomes are posted back to the ticket as comments, so the full context lives where your team already tracks it.
  </Step>

  <Step title="The ticket transitions">
    On completion, the agent transitions the ticket so your board reflects reality without manual bookkeeping.
  </Step>
</Steps>

## Slack

Slack chat is generally available. Bring a capable agent — with its skills and its own sandbox — into the channels your team already uses. There is nothing to install and nothing to learn.

Non-technical teams especially love it: instead of a new interface, they get an assistant right where they already talk. Ask a question, get an answer with citations, and watch the agent's tool calls as it works. And you decide how much of that work each channel sees — from clean answers only to the full detail of thinking, tool calls, results, and errors, configurable per agent and per sandbox.

### Skills become simple tools — for everyone

Slack is where agent capability spreads beyond the people who build it. Skills are authored once and exposed to everyone else as simple tools, so the people closest to the work can run real automation themselves.

<Steps>
  <Step title="Author once">
    Someone on your team writes a skill by working with an AI agent — on their own machine or in a sandbox — and saves it to GitHub, versioned like any other code. Builders are often engineers, but they don't have to be.
  </Step>

  <Step title="Expose safely">
    An admin uses Olyros Code workflows to surface that skill as a simple tool, directly available in Slack.
  </Step>

  <Step title="Run it where you work">
    Non-technical teammates run the tool in the channel they already use — no scripts passed around, nothing to install, and no credentials ever in their hands.
  </Step>
</Steps>

The security consequence is worth stating plainly: instead of sharing credentials, spreadsheets of API keys, or copy-pasted scripts, your organization shares capability. The secrets stay in the platform — scoped, short-lived, and invisible to the person running the tool — so security gets better as adoption spreads, not worse.

### Build skills in a sandbox, right from Slack

For the people between "user" and "developer," sandboxes remove the hardest part of building automation: the environment. Develop and iterate on new skills in a governed sandbox reached through Slack — no libraries to install, no local setup.

This is how skill builders emerge outside engineering. Every team has its adventurous one — the person in sales, support, or marketing willing to learn to work with an agent — and a sandbox turns that willingness into working tools. With a bit of guidance, their skills can be published for the whole company to use.

<CardGroup cols={2}>
  <Card title="Nothing to set up" icon="wand-magic-sparkles">
    Start building in a ready-made, isolated workspace. The toolchain is already there; you bring the idea.
  </Card>

  <Card title="Remote support built in" icon="handshake-angle">
    Stuck? A colleague can join your sandbox and help directly — support without screen-sharing gymnastics or shipping files around.
  </Card>
</CardGroup>

Every sandbox is contained and audited like the rest of the platform, which is exactly why IT can say yes to it.

## Scheduled work

Some work should just happen on its own. Recurring schedules let agents run on an interval and report into the same systems your team already uses for planning.

This is the natural next step for a skill your team already trusts: what someone ran by hand last month becomes a report that writes itself every Monday, an analysis that lands before standup, or a security audit that runs nightly — with every run on the record.

<CardGroup cols={2}>
  <Card title="Flexible, timezone-aware schedules" icon="clock">
    Run tasks hourly, daily, weekly, monthly, or on a custom interval — with a timezone picker so runs land when you expect them.
  </Card>

  <Card title="Work that shows up in sprints" icon="list-check">
    Schedules can create tickets on your existing GitHub or Jira board, so agent work appears in normal sprint reporting alongside human work.
  </Card>

  <Card title="Overlap policies" icon="layer-group">
    Decide what happens when a run is still going as the next one is due, so long-running tasks never pile up unexpectedly.
  </Card>

  <Card title="Auto-pause on failure" icon="circle-pause">
    A schedule automatically pauses after repeated failures, so a broken task stops instead of running — and costing — endlessly.
  </Card>
</CardGroup>

Every schedule keeps a per-run history with the cost of each run, so you always know what recurring automation is spending.

## Model providers

Bring your own provider credentials and use the models you already trust.

<CardGroup cols={3}>
  <Card title="Anthropic Claude" icon="robot" />

  <Card title="OpenAI" icon="brain" />

  <Card title="Google Gemini" icon="google" />

  <Card title="AWS Bedrock" icon="aws" />

  <Card title="Azure" icon="microsoft" />

  <Card title="Other models" icon="plug">
    Generic support for adding additional models beyond the providers above.
  </Card>
</CardGroup>

Because you connect your own credentials, usage stays on your accounts — and Olyros Code breaks down usage per provider so you can see exactly where spend is going.

## Get started

<CardGroup cols={2}>
  <Card title="Get Started" icon="rocket" href="https://client.olyrosstudios.com">
    Create your workspace and connect your first integration.
  </Card>

  <Card title="Book a Demo" icon="calendar" href="https://calendly.com/olyros/30min">
    See agents working inside GitHub, Jira, and Slack on a live call.
  </Card>
</CardGroup>
