Most teams building an AI assistant hit the same wall around week three. The demo works beautifully on five clean PDFs. Then someone points it at the real corpus, 40,000 files spread across Slack, SharePoint, a decade of email, and a folder called “final_v3_ACTUAL”, and the answers fall apart. Graphlit Agents exist to solve that specific problem.
What Graphlit agents actually are
Graphlit is a managed platform for the unglamorous half of AI: ingesting unstructured content, extracting meaning from it, and serving it back through a searchable API. The agent layer sits on top of that pipeline. Rather than wiring together a vector store, an embedding model, a chunking strategy and a retrieval loop yourself, you define an agent, point it at content that has already been indexed, and let it answer questions or work through multi-step tasks.
The difference from a prompt wrapper is grounding. A generic chatbot with a system prompt will happily invent a contract clause. A Graphlit agent retrieves the actual clause, cites the document it came from, and can call a web search tool when the internal corpus has nothing useful to say.
The anatomy of a Graphlit agent
Agents here are configuration objects, not code you write from scratch. A definition typically carries six things:
- Name and description — a short statement of purpose that shapes how the model frames its own behaviour. Vague descriptions produce vague agents.
- Model — you choose the LLM, and you can swap it later. Claude, GPT models and others route through the same interface, so upgrading a model is a config change rather than a refactor.
- Tools — the capabilities the agent may invoke mid-run.
- Sources — which collections, feeds or individual items the agent is permitted to search.
- Conversation settings — memory behaviour, retrieval filters, and how much context gets pulled into each turn.
- Observability — a record of what the agent retrieved and which tools it called, which is the only practical way to debug a bad answer.
Agent flavours you’ll actually use
A general-purpose built-in agent handles straightforward retrieval-augmented question answering. A deep research agent is built for longer investigations: it issues a search, reads the results, notices a gap, and refines its next query. Several rounds later it produces a synthesised answer rather than a list of links.
Custom agents are where the real value sits. A contract-review agent and a market-trends agent should not share a prompt, a temperature, or a source list. Narrow scope is the cheapest accuracy improvement available to you.
Connectors do the boring work
Ingestion is where most homegrown RAG projects quietly die. Graphlit ships connectors for the usual suspects: Slack, Google Drive, Notion, email, RSS feeds, object storage, websites, plus file uploads. PDFs get parsed, images get OCR’d, audio and video get transcribed, and extracted entities get linked into a knowledge graph. If you have ever spent a fortnight arguing about chunk overlap, you understand why handing that job to a service is appealing.
Tools are what turn answers into actions
A retrieval-only agent is a search engine with better manners. The interesting behaviour starts when the agent can reach outside the corpus.
Web search lets it check whether a policy changed since the document was ingested. Trend search surfaces what people are saying right now, which matters for anything time-sensitive. Deep research tooling handles the multi-hop questions that a single query cannot answer. And through the Model Context Protocol, you can expose your own internal services as tools: a pricing lookup, a ticketing system, a database query. The agent decides when to call them.
That last point has a practical consequence. Because Graphlit acts as an MCP server itself, an agent you configure can be reached from Claude Desktop, Cursor, or any other MCP-compatible client. Your retrieval layer becomes infrastructure other tools consume, not a bespoke integration per app.
Grounding beats model size, every time
Teams routinely over-invest in the frontier model and under-invest in retrieval. In practice a mid-tier model with tight, well-filtered context outperforms a top-tier model guessing from its training data. The reasons are mundane: your internal documents contain facts that were never public, your terminology differs from the general web, and your data changes weekly.
This is why the source filter matters more than the temperature setting. If you can restrict an agent to the twelve documents that govern a process, do that. Restricting scope to a few hundred relevant chunks does more for answer quality than any prompt engineering trick.
Building your first agent without over-engineering it
The platform is API-first: a GraphQL endpoint plus SDKs for Python, TypeScript and .NET, so agents slot into existing services rather than demanding a new stack. A sensible build order looks like this.
- Ingest one messy source properly and check the extracted text. Garbage in, confidently wrong out.
- Create a general agent over that source and ask twenty real questions your team would ask. Note every failure.
- Convert it to a custom agent with a description and source filter that reflect what you learned.
- Add external tools only once retrieval alone is reliable.
- Instrument conversations so you can trace which chunks produced which sentence.
Step two is the one people skip. Twenty real questions will tell you more about your corpus than any architecture diagram.
Where these agents earn their keep
The strongest fits share a shape: high document volume, strict accuracy requirements, and people who currently spend their afternoons searching.
- Competitive intelligence teams monitoring filings, earnings calls and news, where the answer needs a citation trail.
- Media and newsroom workflows that need to search a decade of archive alongside today’s reporting.
- Legal and compliance review, where a missed clause is expensive and retrieval precision beats creative fluency.
- Support copilots that read past tickets, runbooks and release notes, then draft a reply a human edits.
- Sales enablement, where the question “what did we promise this account in 2023?” has a definitive answer sitting in an email thread.
Weak fits tend to be tasks with short, structured data. If your whole knowledge base is a tidy Postgres table, you do not need an ingestion pipeline.
Trade-offs worth weighing before you commit
Managed means someone else handles scaling, transcription queues and connector breakage. It also means you are renting a layer that would take a quarter to rebuild, and pricing generally runs on credits tied to ingestion volume, storage and inference calls. For a pilot that is fine. At scale, model your expected monthly ingestion before you sign anything, because content never stops arriving.
There is also a latency reality. An agent that retrieves, reasons and then calls two tools takes noticeably longer than a plain completion. Users tolerate four seconds for a well-sourced answer and resent twelve seconds for a mediocre one, so streaming partial results matters.
A first project that pays for itself
Pick the one question your team asks repeatedly and answers manually today. Ingest only the sources that bear on it, maybe three or four. Build one custom agent with a narrow description and no external tools. Measure how often the answer is right and how long it took to find. If that agent saves an hour a week across five people, you have a case for expanding scope, adding web search, and connecting it to your other MCP clients. If it does not, you have learned something cheap about your data, which is a better outcome than discovering it after six months of building your own pipeline.