Your agents can now search your company's files, and every answer they give can be rated once, however many calls it took to produce.
Knowledge Stack turns uploads, Amazon S3, Google Drive, OneDrive and SharePoint into one knowledge base your agents can search. The Feedback API now takes one rating for up to 25 requests, lets you weight it, and rejects bad input before it's stored.
Using the Feedback API? Redeploy your project to turn the changes on, and check what gets rejected before you do.
NEW · KNOWLEDGE STACK
Give your agents your company's files, and keep them in sync
Uploads, S3, Google Drive, OneDrive and SharePoint, indexed into one knowledge base that your flows, Studio and the Developer API can search.
Your support agent can only answer from what it can look up. The refund policy is in Google Drive, the product specs are in SharePoint, and the exports land in S3. All of them change every week.
Knowledge Stack turns those files into a searchable knowledge base for your agents. Add documents from uploads, Amazon S3, Google Drive, OneDrive or SharePoint, and Lamatic indexes them into a vector collection. Your flows, Studio and the Developer API can all search it, and sources can resync on a schedule, so the stack keeps up with the files it comes from.
Example: a support agent that answers from your help center
In Studio, open Context Stores, create a stack called support-docs and add your Help Center folder in Google Drive as a source, set to resync every day. Index it once with an embedding model. From then on, new and changed articles are indexed automatically, and your agent can search the stack before it answers:
API="https://developer-api.edge.lamatic.tech/v1/projects/$PROJECT_ID/knowledge"
curl -X POST "$API/stacks/$STACK_ID/search" \
-H "Authorization: Bearer $LAMATIC_TOKEN" \
-H 'Content-Type: application/json' \
-d '{"query": "How long do refunds take?", "searchType": "hybrid", "limit": 5}'
How it works
Add sources. Upload PDF, DOCX, XLSX, CSV, JSON, HTML, Markdown or plain text files, or connect Amazon S3, Google Drive, OneDrive or SharePoint. Sources can filter by folder and file pattern.
Index. Pick an embedding model, and Lamatic extracts, chunks and embeds each document on your project's pod. You can track every document from pending to indexed. The Activity tab shows each sync and index job with per-file outcomes, failures first.
Search. Use hybrid search (the default), vector or keyword, from your flows, Studio or the Developer API.
Stay in sync. Connector sources can resync every hour, 6 hours, day or week. New and changed files are indexed with the stack's existing model, and deleted files are removed from the index.
The details
Your files stay in your project. Every file is stored in your project's own bucket, which is created with its first file and deleted with the project. API uploads go straight to storage through presigned URLs and never pass through the API. The same file isn't stored twice in one stack.
One embedding model per stack. A stack stays on the model it was first indexed with, and search uses the same model, so the vectors always match. To change models, re-index, which rebuilds the collection.
Per-document results. Each document is indexed as its own run. It ends up indexed with a chunk count, or failed with the node that failed and its error message.
Scheduled sync. A schedule runs as the person who set it. If that person can no longer edit the project, the run is recorded as an error rather than run under someone else's access. Three failed runs in a row pause the schedule, and saving the schedule again resumes it.
Changed files settle first. A changed file is indexed once it has stopped changing. A scheduled sync waits one interval before indexing a new version, and a manual sync always takes the latest version.
Developer API. 19 new endpoints under /v1/projects/{project_id}/knowledge cover stacks, documents, uploads, indexing, jobs, sources and search. Indexing, re-indexing and sync return 202 {"jobId"} right away. Poll GET /jobs/{job_id} for progress, with failed files listed first.
Token scopes. knowledge:read (minimum role: viewer) lists stacks, documents, jobs and sources, and runs searches. knowledge:write (minimum role: editor) creates, renames and deletes stacks, adds and removes documents, and handles uploads, re-index, sync and cancelling jobs. knowledge:run (minimum role: developer) starts an index.
Limits. 25 MB per file and 50 files per upload call. Presigned upload URLs are valid for 15 minutes. Text documents sent through the API can be text/plain, text/markdown, text/csv, text/html or application/json, within the API's 1 MB request limit. Each index round takes up to 50 documents, and larger stacks continue automatically. Stack names can be up to 64 characters and descriptions up to 300. The shortest sync schedule is 1 hour.
Before you start
Mint a new personal access token. Existing tokens don't carry the knowledge:* scopes.
Deploy the project. Indexing runs on your project's pod, so the project must be deployed and must have at least one API key from before its latest deploy.
Add an embedding model credential. Your project needs one that can create embeddings, for example OpenAI or Cohere, before it can index.
IMPROVED · FEEDBACK API
Rate the whole answer, not just one call
One feedback submission can now cover up to 25 requests and carry a weight, and it's checked before it's stored.
Your support flow answers a ticket in two calls: one classifies it, and one drafts the reply. The customer gives the answer 5 stars, and until now you had to pick one request for the rating, or send it twice and count it twice. Your LLM judge's shaky verdicts also counted as much as a confident reviewer's. And a rating of 4.5 was stored without a warning, only to show up weeks later as an odd number in Reports.
The Feedback API now fixes all three. One submission can cover several requests and carry a weight from 0 to 1, and bad input is rejected up front with every problem listed.
“Redeploy to turn this on. Existing projects pick up these changes the next time they're deployed. Redeploy any flow in your project to get them, and check what gets rejected (at the end of this section) before you do.”
Example: rate a two-call answer once
Your app already gets a requestId back from each flow run. When the customer taps the stars, send one submission for both calls:
// Two flow runs answered one ticket. The customer tapped 5 stars.
const res = await fetch(LAMATIC_ENDPOINT, { // your project's GraphQL endpoint
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.LAMATIC_API_KEY}`,
"x-project-id": PROJECT_ID,
"Content-Type": "application/json",
},
body: JSON.stringify({
query: `mutation SubmitFeedback($requestId: String, $requestIds: [String!],
$rating: Int, $weight: Float, $comment: String, $metadata: JSON) {
submitFeedback(requestId: $requestId, requestIds: $requestIds, rating: $rating,
weight: $weight, comment: $comment, metadata: $metadata) {
success message data error
}
}`,
variables: {
requestIds: [classify.requestId, draft.requestId],
rating: 5,
},
}),
});
const { submitFeedback } = (await res.json()).data;
// submitFeedback.data.feedbackId: one ID, shared by both requests
// submitFeedback.data.results: [{ requestId, success }, ...]Scoring with an LLM judge instead? Send the same mutation with the judge's confidence as the weight, so an unsure verdict counts for less:
variables: { requestId: draft.requestId, rating: verdict.score, weight: verdict.confidence }
// rating must be a whole number; weight is between 0 and 1
How it works
Run a flow through the API and keep the requestId from the response.
Call submitFeedback with either requestId, or requestIds for up to 25 requests. Include at least one of rating, weight, comment or metadata.
Read feedbackId from the response, plus the per-request results if you sent requestIds. Ratings show up in Reports and Logs.
Your project's submitFeedback reference lists the full payload, with cURL, Node.js and Python snippets you can copy.
More ways to use it
Approve up to 25 outputs from a review queue in a single call.
Count submissions, not rows. Group by feedbackId so one rating spread across three requests doesn't look like three ratings.
Catch a broken feedback integration the day it ships, not weeks later in Reports.
The details
What's new
weight (optional, 0–1). How much a piece of feedback should count, such as a confidence or importance score. Example: "weight": 0.8.
requestIds (optional, up to 25). Send one piece of feedback for several requests at once, instead of requestId. The feedback is attached to each request, so it shows up on every one. Duplicate IDs are ignored.
feedbackId in the response. Every submission now returns one. When feedback goes to several requests, they all share the same feedbackId, so you can tell they came from one submission.
Per-request results. A multi-request submission returns a result for each request ID. If some fail, the response says so, for example "Feedback submitted for 1 of 2 requests". Feedback for the requests that succeeded is still stored.
What's stricter
Bad input is now rejected with every field error listed at once, instead of being stored silently. Nothing from a rejected submission is stored.
rating: a whole number. 1–5 is recommended, and 0–255 is accepted.
comment: up to 5,000 characters.
metadata: a JSON object (not an array or a string), up to 16 KB, nested up to 5 levels deep, with up to 100 keys.
Send exactly one of requestId or requestIds. Sending both, or neither, returns an error.
Every submission needs at least one of rating, weight, comment or metadata.
Reports and Logs are based on ratings. Feedback without a rating is stored, but may not show up there.
Heads-up: what gets rejected after you redeploy
Some input that works today will be rejected once your project is redeployed:
Decimal or negative ratings (4.5, -1)
Metadata that isn't a JSON object, such as a string or an array
Comments or metadata over the limits above
Empty feedback with no rating, weight, comment or metadata
If your app sends any of these, fix it before you redeploy, or those submissions will start returning errors.
