Agents#
An agent is the colleague you talk to. Not a chatbot session that forgets you, and not a workflow graph: a configured, persistent participant with its own prompt, model, tools, memory and history, sitting in your channels.
The limitation this page is about: a working agent used to be something one engineer set up for themselves. On LIT an admin sets one up once, and everyone on the team has it the next time they sign in.
What an agent is#
Every part of an agent is its own setting in the agent's config, and any of them can be changed without touching the others:
| Part | What it is |
|---|---|
| Prompt | The system prompt, inline or loaded from a file. New agents start with a default that teaches them to keep their own memory. |
| Model | Which model answers, plus a reasoning effort level. Switchable at any time without losing the channel. |
| Harness | The runtime that actually runs the model: Claude Code, Codex CLI, Gemini CLI. LIT spawns the vendor's own harness, it is not one. See Any harness, any model. |
| Seat | The credential the agent bills to: your own subscription, a team-held seat, or an API key. |
| MCP servers | Which tools the agent can reach (Google Workspace, Jira, your own), with per-server overrides. |
| Skills | Discovered from your personal, team and bundled skill folders; an agent opts out of the ones it should not use. See Skills. |
| Working directory | Where the agent's tools run, plus any extra directories it may read. |
| Heartbeat | Whether it wakes on its own, how often, and what wakes it. See Autonomous agents. |
Agents live in your home directory on the server (or on your laptop on the desktop). Each has its own sessions, turn files and memory folder. Conversations belong to agents; a channel names the agent that answers in it.
Provisioned agents#
An admin opens the team policy, names the agents every member should have (or every member of a group), and saves.
That save snapshots each named agent from the admin's own definition into a team-owned template: prompt inlined, tools and skills as configured, the admin's own folders and sessions stripped out. Every current member who lacks the agent gets a copy registered in their home. Anyone who joins later gets it at sign-in. The copy is bound to the team's seat for that vendor, so a new member does one sign-in and is chatting with a working agent that bills to the team.
The template is the seed, not a live link. Members keep their copy, memory and all; the admin's later edits produce a new template for new members, they do not overwrite what someone has already taught their agent. Each provisioning is an audit event with the member, the agent and the seat it was bound to.
Provisioned agents run under the same rules as everything else on the team: model allow-lists, MCP allow-lists, spend budgets and the kill switch all apply. Seats & Policy →
The agent can ask you a question#
When a harness needs a decision (Claude Code's ask-the-user prompt, a permission it does not have, a session it wants to resume), the question does not stall in a terminal nobody is watching. It arrives in the chat as a card with the options. Tap one and the answer goes back to the harness; the card locks with your choice shown, and the exchange is part of the channel history.
This works in the web app, on a desk or on a phone, and in the desktop app. The same card carries a credential that needs re-authenticating: a one-click sign-in, well timed, in the chat. LIT never authenticates on your behalf. A person always signs in; the platform only makes it one tap.
Presence#
The status dot next to an agent's name tells you what it is doing: idle, receiving, processing, sending, or offline. While it works you see a typing indicator, then the tool calls and text streaming in as they happen. There is no separate progress screen; the conversation is the telemetry.
Reactions go both ways. You can react to an agent's message with an emoji, and an agent can react to yours: a thumbs-up when it has read something and has nothing to add. Agent reactions are a Labs feature you switch on per user; when it is on, the agent posts a reaction instead of a reply when a reply would be noise.
More than one agent#
Several agents can share a channel. One owns it and answers by default; the others are in the room and answer when mentioned with @name, each with full access to the channel history. Because each agent carries its own model and harness, this is also how you put two models on the same question.
Agents can also message each other directly. An agent with the messaging tool sends a message to another agent with a priority; it lands in that agent's inbox, and the inbox is one of the stimuli that wakes an agent on its next heartbeat. A coordinator agent handing work to specialists is the usual shape. Every message in the exchange is on the record like any other turn.
What LIT does not do is draw the org chart for you or route work through a graph. The model decides who to ask and what to say; the platform gives it colleagues, a mailbox and a record.