The agent proposes,you approve every write
A stand-up leaves you with a pile of work that changes shape every day: two tickets to create, one to comment on, a page to append, a message to post. A scripted workflow cannot know that in advance. Khint's Super Khint step reads your notes, proposes each write with its target already filled in, and runs nothing at all until you click Run on that row.
A fixed script cannot
match a variable meeting
A saved workflow is scripted on purpose: when you build it you pick the write and its target, and every run does exactly that. It is the right contract for a job you repeat, like turning notes into one ticket in one project. It is the wrong contract for a meeting, because a meeting produces a batch of actions that varies in number and in kind. Some days it is three tickets. Some days it is two comments on tickets that already exist and a follow-up email. Super Khint inverts the contract: the model reads the content and proposes the list, and your control moves from framing the work in advance to approving it before it is written. The writes themselves are the same integration writes every other workflow uses.
The real palette running a saved workflow: the notes leave the document and the writes land in Jira, Confluence and Slack. Super Khint keeps those writes and puts an approval row in front of each one.
From raw notes to approved writes
Turning a daily stand-up transcript into the tickets, comments and messages it actually calls for.
Save a Super Khint workflow
Super Khint has its own entry in the sidebar, and what you create there is still a workflow: it stays in your workflow list wearing a Super Khint chip. Pick where its input comes from, a selection, your clipboard, or a document, and optionally write a short brief to steer it, something like “project ENG, post the summary in #standup”. The brief is optional. Left empty, the planner simply proposes what the input calls for.
Feed it the notes in full
Copy the transcript, select the notes in your doc, or point the workflow at a file, then open the palette with Cmd+Shift+K and run it. This step deliberately skips the summarising layer other document agents use: a condensed transcript loses the per-ticket detail, and per-ticket detail is exactly what has to survive for the proposal to name the right issues.
The planner proposes a list, not a paragraph
One model call reads the notes and returns a list of actions across the integrations you have connected, and only those: create a Jira issue, comment on one, append to a Confluence page, add a Notion page, open a Linear issue, post to Slack, draft a Gmail message, or simply put text on your clipboard. A paused integration is invisible to it. If you have turned on Khint's local Knowledge index, the planner also sees excerpts from your own Jira and Confluence content, which is what lets it comment on the ticket you already have instead of creating a second one.
Approve each action on its own row
The palette shows one row per proposed action: which tool, which target, and a preview of what would be written. Each row has its own Run button, and nothing happens until you press one. Run the first, read the receipt with the key or the URL that came back, then decide about the second. Where the model cannot know a value, a Jira issue type, a Confluence space, a Linear team, the row asks you with the same picker the rest of the palette uses. A failed row offers Retry and leaves the rows around it alone.
Close the run and keep the trail
Skip the rows you disagree with, they simply never run. When you close the card, Khint records the run once in your history, and each write that landed has already logged an entry against your active Memory session with the link back to the ticket or page. The next morning you open the same workflow on a new transcript and get a different list, because the list comes from the content and not from the script.
Two honest ways to automate a meeting
Both ship in Khint. Pick by whether the work repeats identically or changes with the content.
A scripted workflow
You fix the steps and the targets when you save it, and every run does exactly that.
How workflows work- Best when the job repeats: the same ticket in the same project, every time
- Runs on your own keyboard shortcut, with no window to look at
- Can fan out to several tools at once, all receiving the same text
- Cannot add a write the content asks for, because it was never in the script
Super Khint
The planner reads the content and proposes the list. You approve it row by row.
Download Khint Free- Best when the batch changes every time: a stand-up, a discovery call, a review
- Runs from the palette, because the approval card needs somewhere to appear
- Can comment on tickets you already have, not only create new ones
- Nothing is written until you click Run on that specific row
What it refuses to do
The boundaries are the product. An agent that quietly widened them would not be worth approving.
No unattended mode
There is no setting that runs the proposed list for you. Every action needs an explicit click on its own row, and a run you close early simply stops there.
No keyboard shortcut
A Super Khint workflow runs from the palette rather than a global shortcut, because the approval card has to be visible. That also means it cannot be started by voice.
It is the whole workflow
Super Khint is the only work step in its workflow, so it does not sit in the middle of a longer chain. Scripted steps and this step stay separate workflows.
Nothing is dropped in silence
An action naming a tool you have not connected, or one the planner got wrong, appears on the card as a line you can read. It is never quietly removed from the list.
What landed stays landed
If one approved write fails, the ones that already succeeded are not rolled back. A message posted to Slack cannot be un-posted, so Khint reports the failure instead of pretending it can undo it.
One billed action per run
The planner call counts as one AI action. The writes you approve call no model at all, so approving five of them costs nothing beyond that first call.
The approval card is also the security boundary
Notes you paste are untrusted text, and a transcript can contain a sentence written to steer a model. Khint wraps that content as data before the planner sees it, but the stronger defence is the one you can see: an action nobody in the meeting asked for shows up as a row on the card, and you do not press its Run button. That is the practical difference between an agent with tool access and an agent with tool access plus a person. If the notes themselves are sensitive, you can also redact PII before the call, or read how integrations keep their credentials in your system keychain.
Common questions
What does human-in-the-loop actually mean here?
It means no write reaches one of your tools without a person pressing a button for that specific write. Khint's Super Khint step splits the job in two: a planner reads your notes and proposes a list of actions with their targets filled in, and then the palette shows you that list with one Run button per row. Reading and proposing are automatic. Writing is not. You can run three of the six proposed actions, change a target, retry a failure, and close the card on the rest.
How is this different from a normal Khint workflow?
A normal workflow is scripted. When you build it you choose each step, each integration write and its target, and every run repeats that exactly. It is the better tool when the job is identical every time. Super Khint is for the opposite case: the model decides how many actions there are and what they point at, based on the content you gave it. One stand-up might produce two tickets, another might produce a comment on an existing ticket and a Slack post. A scripted chain cannot represent that, and a script that guessed would be worse than one that asked.
Can it update tickets that already exist, or only create new ones?
It can do both, as long as it can identify the existing item. That is what Khint's local Knowledge index is for: it syncs your Jira, Confluence, Notion and Linear content into a search index on your own machine, and the planner gets the most relevant excerpts for your notes. With it turned on, a mention of the work you discussed can resolve to a real issue key and become a comment on that issue. Without it, the planner has no way to know the item exists and will lean towards creating.
What happens if the planner proposes something wrong?
You do not run that row, and nothing happens. If the target is wrong rather than the action, you can change it on the card with the same picker the rest of the palette uses, which is also how you fill in values the model cannot know, like a Jira issue type or a Confluence space. If a row names an integration you have not connected, it appears as a visible unmet line rather than disappearing, so you always see the full proposal and not a filtered version of it.
Does my meeting transcript leave my machine?
The transcript is sent to the model for the single planner call that produces the proposal, the same way any AI action sends the text you selected. It is not stored on Khint's servers as a document, your Memory sessions stay in a local database on your machine and are never synced, and the Knowledge index is built and searched entirely on your Mac or PC. If you would rather run the call on your own provider account, Khint supports bringing your own API key.
Let the agent propose, keep the last word
Free with 300 credits a month, about 10 AI actions a day. No credit card. Connect a tool, paste your notes, and approve the writes one at a time.