DEV Community: Pachca

Our AI agent lives in team chat. These 4 guardrails keep it from running wild

Pachca — Tue, 20 Oct 2026 15:53:43 +0000

Most AI agents live in their own window. You open it, explain the context, copy in the bug report, paste the answer back somewhere else.

At Pachca we build a team chat app, so we tried the opposite: an agent that lives where the work is already being discussed. Someone @mentions it in a thread, and it reads the conversation, picks the tools it needs, does the work and replies in the same thread.

Here's how it's put together, and the guardrails we added so that a program with tools and API tokens can be trusted in a room full of people.

What it actually does

A normal chatbot answers. This agent chooses tools and runs a chain of actions before replying. The jobs it gets most:

A task from a discussion. It reads the thread, writes a title, description and priority, creates the task in the tracker and links back to the thread.
"Why did the build fail?" Asked in a PR thread, it checks the CI status, reads the logs and may suggest a fix.
File analysis. It fetches a file from the repository or a web page, explains the code, points out problems and suggests improvements.
Company research for sales. Given a company name, it finds the website, estimates the team size and posts a structured report in the thread.

Each of these used to take a handful of manual steps. Now it's one mention in the conversation where the question came up.

Threads are the unit of work

Every thread is a separate conversation for the agent. It doesn't mix up a bug discussion with a release discussion, several agent conversations can run in one channel at the same time, and the main channel stays clean.

Threads also handle the hand-off to people. In Pachca you can @mention someone in a thread even if they aren't in the original chat, and they see the full history. So when the agent finds that failing tests trace back to a change in the auth module, it can tag the developer from another team, and that person gets the whole context from one notification.

The loop

The architecture is deliberately simple:

Webhook in. Pachca sends an event for every message. The agent checks the HMAC-SHA256 signature and acts only when it's mentioned or someone replies to it. Everything else is skipped silently.
Prompt assembled per call. System instructions and tool descriptions, the relevant skills, the last 20 messages of the thread, the message the thread started from, and the user's personal settings such as language or default tags.
Tool loop. The model calls tools it chooses itself: the messenger API, the task tracker, version control (read files, commit, open pull requests) and web search. It isn't a fixed pipeline.
Replies through the API. The agent posts its messages itself instead of returning them in the webhook response. That lets it send more than one message, pick a thread, and put an animated "thinking" reaction on the message while it works.

Behavior lives in Markdown, not code

What the agent knows how to do is described in skill files: plain Markdown with the available actions, required fields, naming rules and example requests. A tracker skill, for example, tells it how tasks should be titled and which fields can't be empty.

It keeps iteration cheap. A new skill needs no code change. Each organization can have its own skills. And when the agent does something wrong, fixing the text of the skill is often enough.

The 4 guardrails

An agent with tools and tokens can also do the wrong thing very fast, or the same thing forever. These limits are what keep it predictable:

Guardrail	Limit	What it prevents
Cooldown	No new run in a thread within 5 seconds of the last one	Double triggers and ping-pong between messages
Step limit	15 tool calls, then it stops and reports an error	Endless tool loops
Timeout	5 minutes for the whole run	Runs that hang and hold resources
No monologues	At most two messages in a row without a human reply	An agent talking to itself in a channel people read

And two boundaries on access:

It sees only where it was called. The agent sees the thread or chat it was mentioned in, not other channels. Confidential discussions elsewhere stay out of its view.
Each organization decides what it can reach. The tracker and Git are connected through API tokens per organization. One agent instance can serve several organizations, each with its own token, webhook signing secret and integrations, with no data overlap.

What we'd tell anyone building something similar

Put the agent where the context already is, make the thread its unit of work, keep behavior in editable text, and decide the limits before the first run, not after the first incident. The model matters, but in our experience what goes into the prompt decides most of the quality.

Next on our list are proactive features: weekly digests of key decisions, warnings about risks in open tasks, and reminders about forgotten pull requests and pending reviews.

I'm curious how others handle this: what limits do you put on an agent that can act inside a shared space? Step caps, timeouts, human approval, something else?

Pachca is the messenger where people and AI agents get work done together. Developer docs for agents are at dev.pachca.com.

How to bring your Claude Code or Cursor agent into team chat

Pachca — Mon, 19 Oct 2026 13:48:05 +0000

Coding agents have become good at reading code, running commands and opening pull requests. But most of the context they need doesn't live in the repository. It lives in team chat: the bug report from support, the decision in a thread last Tuesday, the release checklist pinned in a channel.

This guide shows how to give a coding agent on your machine (Claude Code, Cursor, Codex or any agent with shell access) access to team chat, using Pachca as the example. The whole setup takes a few minutes.

Why a CLI and not a pile of docs

There are two ways to teach an agent a new API. You can load the documentation into its context, or you can give it a tool it can explore on its own.

The first approach is quick for one-off tasks. Pachca, for example, publishes an llms.txt file, so you can drop one link into a prompt and the agent will figure out the API. For regular work, though, documentation eats the context window. A CLI solves this: the agent discovers commands through --help and loads only what the current task needs. That's why Pachca's docs recommend the CLI as the main path for agents.

Step 1. Install the CLI

The Pachca CLI needs Node.js 20 or later. You can run it without installing, which works well for agents with temporary environments:

bash npx -y @pachca/cli api ls --token YOUR_ACCESS_TOKEN

Or install it globally for everyday use:

bash npm install -g @pachca/cli

Step 2. Sign in

On your own machine, sign in through the browser:

bash pachca auth login

The CLI shows a confirmation code, copies it to the clipboard and opens the browser. You confirm access in Pachca, and the terminal shows who you're signed in as. The token from this login lasts an hour and renews itself before each command. If several agent processes run in parallel, only one of them refreshes the token while the others wait.

The token goes into your operating system's keychain, not a plain file. That matters with agents: code running under your account (postinstall scripts, editor extensions, other agents) can read files in your home folder.

To check what access you have, run:

bash pachca auth status

Step 3. Let the agent explore

Now ask your agent to do something real. It doesn't need instructions on the API, because it can look things up itself:

bash pachca api ls # list of endpoints pachca api POST /messages --describe # parameters and body pachca api POST /messages --docs # full reference

Typical first tasks:

"Read the last 50 messages in the bug reports chat and group them by feature."
"Find the thread about the payment timeout and summarize what we decided."
"Post a short release note to the releases channel when the tests pass."

For the last one, the agent might run something like:

bash pachca messages create --entity-id 123 --content "Release 2.4 is live"

Step 4 (optional). Add skills

If you want your agent to know common workflows without exploring, add Agent Skills:

bash npx skills add pachca/openapi

The command detects installed agents and connects the skills. Each skill covers one area of the API (messages, chats, tasks, search, bots, forms) with a quick start, step-by-step workflows with CLI commands, and the area's limits. They work with 40+ AI agents.

Running the agent without you: CI and headless mode

Browser login needs a person at the terminal. For CI pipelines, scripts and agents that run on their own, create a token in Pachca in advance and pass it through an environment variable from your secrets:

bash PACHCA_TOKEN=$PACHCA_SECRET pachca messages create --entity-id 123 --content "Deploy finished" --no-input

Nothing is written to disk this way. For agents that act without an employee, the docs suggest a bot token with minimal permissions.

Three habits that make this work well

Let the agent draft, not send, when the stakes are high. In Pachca, an agent can put a message into your input field as a draft, and you review and send it yourself. Drafts work with a personal token.

Ask for reports as Markdown files. Pachca renders .md attachments as formatted cards with tables, checklists, code highlighting and Mermaid diagrams, so a long code review or incident summary stays readable in chat.

Keep the agent's work in threads. A thread gives the agent the full context of one discussion and keeps its replies out of the main channel. Teammates can follow along and correct course early.

Where to go next

Once your personal agent works with chat, the next step is often a team agent: one that lives in a channel, is @mentioned by anyone, and replies in the thread. In Pachca, that's a bot that receives messages through an outgoing webhook and answers with its own token. The developer docs at dev.pachca.com walk through it step by step.

Pachca is the messenger where people and AI agents get work done together.