Turn a Study Into a Searchable AI Agent Knowledge Base

Then the analysis died in a spreadsheet — the way analysis usually does.

The most valuable thing about a Study isn't the report. It's that you now hold a structured, de-duplicated, AI-read summary of how your team actually resolves problems. That's exactly the material an AI agent needs to answer the next version of those tickets. This post is a deep-dive on the one feature that closes the loop: turning a finished Study into an AI agent knowledge base — a searchable knowledge source your agents query on live tickets. Macha does it in a single step: push a completed Study run into a knowledge source, and every row becomes an indexed document your agents can semantically search. We'll cover what the push does, how to design a Study for it, and where it falls down.

Studies (and this push) are available on Macha's Professional and Enterprise plans.

The gap: analysis is not knowledge

There's a difference between knowing something about your queue and your agents being able to use it.

A Studies report tells you that 40% of last month's tickets touched billing, or that "shipping delay" is your single biggest cluster. Useful for staffing and roadmap decisions. But none of that reaches the agent resolving ticket #48213 at 2 a.m. — unless the insight is sitting somewhere the agent can retrieve it at answer time.

That "somewhere" in Macha is a knowledge source. It's the same mechanism that powers grounded answers across the platform: you give agents knowledge by uploading documents, crawling websites, or connecting live data, and Macha indexes it so agents can pull the right passage on demand. Small content is injected straight into the prompt; larger content is chunked, embedded, and searched semantically — retrieval-augmented generation, in plain terms. (The mechanics live in the Data Sources docs.)

So the question becomes: how do you get the output of a Study into that retrieval layer without re-typing it into articles by hand? You don't. You push it.

What the push actually does

Open any completed Study run and you'll find a Use as knowledge source action. Confirm it, and Macha turns the run into a knowledge source where each result row becomes one document, indexed through the same embeddings pipeline every other Macha knowledge source uses.

Before it commits, the modal is deliberately honest about what's about to happen:

• How many records become articles — the exact count of rows that will be turned into documents, so a 4,000-row run doesn't surprise you.
• Your plan's source-limit usage — knowledge sources are a metered resource (Starter includes 3, Professional 10, Enterprise unlimited), and the modal shows where this new source lands against your limit before you create it.
• How fields are combined — the columns you select are merged into a single article body per record. One row in, one searchable document out.
• A plan-limit-reached state — if creating this source would exceed your plan, the modal says so up front instead of failing halfway.

That "fields merged into a single article body" detail is the part worth slowing down on, because it's where a good knowledge source is won or lost — more on that below.

A worked walkthrough

Here's the shape of it end to end, using a Study scoped to recent resolved tickets.

1. Run the analysis. The Study produces its grid — summaries, a category, a root-cause note, and a short resolution write-up per ticket. This is the report view you'd normally stop at.

2. Push it. From the run, choose Use as knowledge source, confirm the modal, and Macha indexes every row. A frozen run never changes after this — the source is a snapshot of that analysis at that moment.

3. It appears in your sources. The new knowledge source shows up in the same list as your uploaded PDFs, crawled help center, and connected docs — no separate silo.

4. Attach it to the agents that need it. Open an agent, add the source to its knowledge, and from that point the agent can retrieve those documents when a relevant ticket comes in.

That's the whole loop: analyse the past, index it, point present-day agents at it.

Designing a Study for knowledge (not just a report)

This is the part the generic "turn tickets into a knowledge base" guides miss. A Study built to make a chart and a Study built to make a good knowledge source are not the same Study. Because every selected column is flattened into one document body per row, the columns you choose become the searchable text an agent reads.

Favour rich text columns over flags. A Yes/No — Billing related column makes a beautiful bar chart and a useless knowledge document ("Billing related: Yes" retrieves nothing helpful). For knowledge, you want Short text / Long text columns that carry real substance:

Write the schema like you're writing knowledge. A column such as "Summarise the customer's problem and the exact steps the agent took to resolve it" — with per-column guidance — produces a body that reads like a mini runbook. Add a root cause column and a resolution column and each indexed document becomes a self-contained problem/solution pair, which is precisely the shape semantic retrieval rewards.

Scope to resolved, representative tickets. Knowledge built from solved tickets teaches agents what worked. Pointing the same Study at open or escalated tickets indexes confusion, not answers. Use the Zendesk search query and date range in the Study's scope to keep it to closed, on-topic tickets.

The pragmatic move: run two columns for two jobs in the same Study — your Yes/No and Number columns for the report, plus one or two Long text columns for the eventual knowledge source. One run, both outputs.

How agents use it on a live ticket

Once the source is attached, nothing about the agent's runtime is special-cased. When a new ticket arrives, the agent's retrieval step searches all its knowledge — your help center, your uploaded policies, and now your Study-derived documents — and pulls the most relevant passages into context before it drafts. A ticket that rhymes with a problem your team solved last quarter now surfaces that resolution, in your team's own words, because a row from the Study captured it.

This is why the push matters more than the export. A CSV is read by a human, once. An indexed knowledge source is read by every agent, on every matching ticket, until you replace it.

How this differs from real-time ticket-to-knowledge tools

Macha also ships a Zendesk-marketplace app, Past Tickets AI, that continuously ingests tickets as they're resolved and surfaces suggestions in the agent sidebar in real time. That's the always-on, incremental path.

The Studies push is the deliberate, batch, structured path. The differences are real and you'll often want both:

Run a Study once to backfill your archive into agent knowledge, then let an always-on flow keep it current. Most external guides treat this as one feature; in practice they're two complementary motions.

Watch-outs and when not to use it

This is genuinely useful, but it is not magic, and a few things will bite teams that skip the fine print:

• The source is a frozen snapshot. Pushing a run indexes that run's data as it stood. If your product changes and old resolutions go stale, the documents won't update themselves — you re-run the Study and push again. Treat it as a versioned artifact, not a live feed.
• Knowledge sources are metered. They count against your plan's source limit (3 on Starter, 10 on Professional). A Study-derived source uses one of those slots — worth a thought before you create five of them. The modal shows your usage so you decide deliberately.
• Garbage columns make garbage knowledge. As covered above, a source built only from Yes/No and Number columns is near-useless to retrieve. If the run was designed purely for charts, build a second run for knowledge.
• Mind the data you're indexing. You're turning real ticket content into searchable documents. Scope to the fields and tickets you actually want agents quoting, and keep sensitive PII out of the columns you select to merge.
• It's analysis-derived, not a help-center substitute. This makes internal agent knowledge from your own history. It is not a replacement for customer-facing help-center articles, and Studies itself is Professional/Enterprise-gated.

If your tickets are mostly unresolved, wildly inconsistent, or you only need a one-off number for a slide — skip the push and just read the report.

FAQ

What is a knowledge source in Macha? It's any content your agents can retrieve at answer time — uploaded documents, a crawled website, connected live docs (Notion, Confluence, Google), or, here, a pushed Study run. Larger content is chunked, embedded, and searched semantically, so agents pull the most relevant passage into context. See the Data Sources docs.

What happens to each ticket when I push a Study? Each result row becomes one indexed document. The columns you select are merged into a single article body per record, then embedded into the source so agents can search it.

Does pushing change my original tickets or the Study? No. The run is a frozen snapshot; the push reads from it. Your Zendesk tickets are untouched, and editing the parent Study later doesn't rewrite a source you already created.

Will the knowledge update automatically as new tickets come in? No — a pushed source is point-in-time. To refresh it, re-run the Study over a newer date range and push again. For always-current knowledge, pair it with a real-time ticket-to-knowledge flow.

Which plans include this? Studies and the knowledge-source push are on Professional and Enterprise. Knowledge-source limits scale by plan. See the pricing page for current plans.

Is it expensive? The cost is the Study run itself — credits are charged per successfully processed record, by the model you pick, and you confirm the total before it runs. The push then turns those rows into indexed documents.

Try it

If you've already run a Study, you're one button from making it useful forever: open the run, choose Use as knowledge source, and attach it to an agent. If you haven't, start a 7-day free trial, no credit card required, connect Zendesk, run an analysis over your resolved tickets — and read the Studies docs for the full builder walkthrough. Then point your agents on Zendesk at what they learn.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.