# Work your agents can see

Your issues live in one tool and your customers in another. The reasons behind them live in neither: they're in a call, a thread, a doc. When an agent picks up an issue or prepares a meeting, it sees the ticket or the contact, and nothing around it.

This page explains why that happens, the ways teams solve it, and where Known fits.

## What goes wrong

A bug comes in from a customer. Someone files it in the issue tracker. The customer, what they're paying, and the call where they explained the problem are in the CRM and a meeting note. The decision to fix it this week was made in a chat thread.

An agent asked to fix the bug reads the ticket. It doesn't know who reported it, why it matters now, or what was already tried. An agent asked to prepare the next call with that customer reads the CRM. It doesn't know the bug exists.

People fill the gap by pasting context into each agent, every time.

## Why it happens

Each tool holds one kind of record well. An issue tracker holds issues, a CRM holds contacts and deals, a wiki holds documents. The links between them, such as this issue came from this customer because of this decision, are either missing or stored as text no tool follows.

Most of these tools now have an MCP server, so an agent can read and write issues or contacts directly. That solves access. It doesn't solve context: the agent still reads one tool at a time, and the connections between records aren't there to follow.

## The ways to solve it

| Approach | How it works | Trade-off |
|---|---|---|
| Connect each tool to your agents | Add the MCP servers for your issue tracker, CRM and docs to every agent | Agents can reach everything, but they have to search each tool and join the pieces themselves, every time |
| Write context into each record | Paste the customer, the decision and the call notes into the ticket | Works until it's out of date; it's copied, so it drifts |
| Keep the work in one model | Issues, contacts, meetings and decisions as records in one place, linked to each other | You give up some of a specialised tool's interface; you gain one model every agent reads |

## Where Known fits

In Known, issues, contacts, meetings and decisions are [records](https://known.info/docs/records) in wikis, and records link to each other with [links](https://known.info/docs/links). An issue links the customer who reported it, the decision behind it and the commit that fixed it. A contact links every meeting and introduction. An agent working on any of them can follow the links to the rest.

You define each table's fields with a [schema](https://known.info/docs/schemas), and its page says how to use it. The same agents your team already uses read and write it over [MCP](https://known.info/docs/connect-agent), as the person who connected them, and every change is versioned with who made it.

Known doesn't replace a specialised tool everywhere. If you need boards, cycles, notifications, or email and calendar sync, Linear, Jira and the CRMs do those well, and you can keep them and still keep the context in Known.

## Guides

- [Set up issue tracking in Known](https://known.info/docs/guides/how-to/issue-tracking)
- [How your team and agents work issues in Known](https://known.info/docs/guides/how-to/issues-with-agents)
- [Set up a CRM in Known](https://known.info/docs/guides/how-to/crm)
- [Log a meeting to your CRM from ChatGPT, by voice](https://known.info/docs/guides/how-to/log-meetings-by-voice)
- [How we run our backlog and our fundraise on Known](https://known.info/docs/writing/running-on-known)