Skip to main content

​
Nothing to enable

Once an app is connected, its tools are offered to every agent in your organization automatically. An agent that doesn’t set allowed-tools already has them; an agent that does needs to list the ones it should use. That’s true in chat, too. Ask an agent to “post a summary of this to #security” and, with Slack connected, it can.

​
Naming tools in allowed-tools

Integration tools follow the pattern <App>_<Action>, and the name must match exactly:
  • No wildcards. Jira_* matches nothing. List each tool.
  • Case matters. Jira_CreateIssue, not jira_createissue.
  • The app prefix is the toolkit’s name, not always the app’s. Slack’s send and react tools are SlackApi_…, Asana’s comment tool is AsanaApi_…, Google’s are all GoogleDocs_…. Each app’s page has the exact list.
Listing an integration tool doesn’t connect the app. If the app isn’t connected when the agent runs, the tool is absent and the agent works without it.

​
Prompting

The tools carry their own guardrails, baked into the descriptions agents read: create an issue only when asked and never in bulk, post in a finding’s existing Slack thread rather than starting a new one, read a page before replacing its content. You don’t need to repeat those. What your agent’s instructions should add is the where and what:
  • Name the destination. The Jira project key, the Slack channel, the Confluence space, the Notion parent page. Agents can discover these — Jira_ListProjects, Slack_ListConversations — but an agent told “the SEC project” doesn’t have to guess.
  • Say what one item looks like. A title format, which fields to fill, what to link back to. Console’s findings have ids and URLs; ask for them in the issue body so the two stay connected.
  • Say what to do with nothing. Post “no issues found”, or post nothing? An agent will pick one if you don’t.

​
Adding a delivery step to a workflow

The natural place for integration tools in a workflow is a final step that takes what earlier steps produced and puts it where your team will see it. Console’s built-in outputs deliver to the triggering pull request; a step with integration tools can deliver anywhere an app is connected. Such a step consumes findings, and the mode you choose decides its shape.

​
One message per run

A summary step consumes with mode: all. It runs exactly once, with every finding from earlier in the chain — including none — so it can say “clean” as readily as it can list problems:

​
One issue per finding

A filing step consumes with mode: each. It runs once per finding, and if there are none it’s recorded as skipped rather than running with nothing to file:
group-by: [id] matters here. amplify:finding groups by detection and file by default, which is right for patching but would file one issue for several findings. See group-by.
To make what the step did visible on the run page, have it record an artifact. Declare a kind of your own in produces:, add emit_artifact to allowed-tools, and ask the agent to record each issue’s key and URL:
See defining your own kind.

​
Putting them in a chain

Add the delivery step after the steps that produce findings. A step can only consume a kind an earlier step in the chain produces, and Console checks that when you save the workflow: Two delivery steps that don’t depend on each other may run at the same time. That’s fine for these — they write to different apps — but if ordering matters, have the later one consume something the earlier one produces.

​
In chat

Everything above applies to chat, minus the contracts. With an app connected you can ask directly:
The agent uses the connected app’s tools the same way it uses any other tool, and each call appears in the session’s tool trail so you can see exactly what it read and wrote.

​
Next steps

Slack

Tools and limits for posting and reading.

Atlassian

Jira issues and Confluence pages.

Writing an agent

The AGENT.md format, consumes, and produces.

Tool reference

Everything else an agent can call.