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.
Top comments (0)