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

# Devin

> Launch Devin sessions to work on engineering tasks

Devin is an AI software engineer that works on tasks autonomously in its own environment. The Cargo integration lets a workflow launch a Devin session and use what it produced — structured output and pull requests — in downstream nodes.

## Authentication

Connect to Devin with a service user API key. Create a service user under **Settings → Service users**, give it a role with the `ManageOrgSessions` and `ViewOrgSessions` permissions, and generate a key. The key is only shown once.

### Connection details

| Field               | Description                                        |
| ------------------- | -------------------------------------------------- |
| **API Key**         | A Devin service user API key, starting with `cog_` |
| **Organization ID** | Your Devin organization ID, starting with `org-`   |

Both are on the **Settings → Service users** page. The organization ID is part of every
API path, so a wrong value fails the connection test the same way a wrong key does.

***

## Devin actions

### Launch agent

Create a Devin session and send it a task.

**Configuration**

| Field             | Description                                       |
| ----------------- | ------------------------------------------------- |
| **Prompt**        | The task Devin should work on                     |
| **Session title** | Title shown in the Devin session list             |
| **Playbook**      | A reusable procedure for Devin to follow          |
| **Repositories**  | Repositories to make available to the session     |
| **Devin mode**    | Normal, Fast, Lite, Ultra or Fusion               |
| **Max ACU limit** | Caps how many ACUs the session may consume        |
| **Tags**          | Tags applied to the session, useful for reporting |

The **Playbook** dropdown lists the organization and enterprise playbooks your service
user can see. Preview Devin modes have to be enabled for your organization; leave the
field empty to use the organization default.

**Output**

| Field       | Description                  |
| ----------- | ---------------------------- |
| `sessionId` | Session identifier           |
| `url`       | Link to the session in Devin |
| `status`    | Session status at creation   |
| `title`     | Session title                |

<Note>
  The node completes as soon as the session is created — it does not wait for Devin to
  finish. The Devin API has no callback to announce that a session finished, so there is
  nothing to wait on without polling.
</Note>

That means the output carries the session's identity rather than its results: structured
output, pull requests and ACUs consumed only exist once Devin has done some work, so they
would always be empty here. Follow the session at its `url`, or read it back from the
Devin API with the `sessionId`.

***

## Use cases

<AccordionGroup>
  <Accordion title="Automated code changes" icon="code-branch">
    Turn a qualified request into a pull request without a human in the loop.
  </Accordion>

  <Accordion title="Codebase research" icon="magnifying-glass">
    Ask Devin to investigate a repository and return structured findings.
  </Accordion>

  <Accordion title="Repeatable procedures" icon="book">
    Run a playbook per incoming item so every session follows the same steps.
  </Accordion>

  <Accordion title="Triage at scale" icon="list-check">
    Launch one session per incoming issue and collect the pull requests they open.
  </Accordion>
</AccordionGroup>

***

## Best practices

1. **Give Devin a complete prompt** - Nothing downstream is waiting to answer a follow-up question
2. **Use playbooks for repeated work** - They keep sessions consistent across records
3. **Set a max ACU limit** - It bounds what a single run can cost
4. **Tag sessions launched from Cargo** - It makes them easy to find in reporting, and it is how you correlate a workflow run with the sessions it started