Conversations as the Work-Graph Input — Project Management with Kavanah

What Kavanah reads, what it does not, and how it composes a single view of intent

Almost no team's work originates inside the task tracker. It originates in conversation — a chat thread, an email, a stand-up, a customer call, an AI agent session — and then has to be lifted, re-phrased, and entered into the tracker by hand. The whole point of Kavanah's capture layer is to make that lift automatic, while keeping the original conversation as the source of truth. To do that, the agent has to read a lot of different surfaces and compose them into a single view.

Chat threads — the primary surface

Internal chat is the highest-volume commitment surface in most teams. Kavanah's Messages section gives every workspace a structured chat environment with threads scoped to projects, clients, or ad-hoc conversations. The AI agent has read access to chat threads within its persona's allowed scopes; for the default agent and any persona with the communications scope, that means everything in the team's main channels.

The agent reads threads in two modes. The first is on-demand: when you ask the agent something, it pulls relevant context from recent threads to answer. The second is the background scan that produces task proposals — it watches for commitment-shaped patterns ('I'll send you that by Friday,' 'who's picking this up?', 'we need to follow up on…') and adds candidate tasks to its proposal queue.

The member ACL on a chat thread is honored. A thread restricted to a subset of members is invisible to personas whose ACL does not include those members. This matters: if you stand up an AI Employee with a restricted membership list, it cannot see, and cannot generate tasks from, conversations its members cannot see. That is by design.

AI agent transcripts — the conversation about conversation

Every conversation a member has with the AI agent is itself a commitment surface. When you talk to the agent about a project, the agent often arrives at a list of things that should happen — sometimes by you asking it explicitly, sometimes as a side-effect of working through the problem together. Those proposed actions become candidate tasks, with the AI agent transcript as their provenance.

The finalize step in the AI agent loop (the part of the system that runs after the assistant has decided to act) is where the agent's intentions become concrete operations: tasks created, drafts written, integrations called. If you spend ten minutes with the agent designing a feature, the finalize step turns the resulting plan into a structured task list assigned to the right members, with skills tagged, time estimates attached, and KVN axes populated where possible.

Email — the slowest surface to read, the richest to mine

Email is read through whatever email integration is connected — Gmail (native or via AngelSend) or ProtonMail (via Bridge). The integration syncs envelopes into Kavanah; for Gmail and AngelSend, message bodies are available on read. ProtonMail is envelope-only by default because Bridge is mail-only and bodies require a fresh IMAP fetch.

The agent's pattern recognition on email is more conservative than on chat, because email is conversational across organizations — the commitment might be from a customer or partner, not a teammate — and turning every customer 'thanks, will revert by EOD' into an internal task would flood the queue. Instead, the agent flags email-derived commitments for review and lets you accept, edit, or dismiss.

This is also the surface that supports scheduled email send and drafts. The agent can write a draft for you to review (gmail_create_draft) or schedule a send for a specific time (schedule_email). Both flows produce audit-trailed actions; both flows respect the same KVN-aware rules the rest of the system uses.

Request pages — the external front door

Public request pages are tokenized intake forms that let external people — clients, prospects, internal teams without seats — submit requests that land as app_requests rows. They can include custom fields (per-page), file attachments, and optional email verification.

From the work-graph point of view, request submissions are conversations with the outside world. Each submission is a candidate task, with the public form as its provenance. The agent surfaces new requests on the Dashboard and in the /requests view; converting a request to a task is one click and inherits the requestor's contact info, attached files, and custom field responses.

If you run a team that takes inbound work from a wide audience — agency, consultancy, support-heavy product — request pages are how you close the lossy-capture loop on the outside-of-the-team boundary. Without them, every external ask has to be re-entered by a human at the front door.

Calendar — the temporal frame

Calendar feeds (Google Calendar, AngelSend Calendar) do not produce tasks directly. They produce temporal context the agent uses to schedule and prioritize. When a task has a due date, the agent checks the relevant calendars to identify conflicts. When a new commitment lands with a vague time horizon ('next week'), the agent resolves it against the team's actual capacity.

The calendar surface also powers the auto-refresh in the in-app calendar shell — connected calendars re-pull every 60 seconds and on window focus, so the view never goes stale during planning sessions.

How the surfaces compose into a single work-graph

The agent does not maintain a separate model of each surface. It maintains a single work-graph of intents, with each intent tagged by its source. A commitment that shows up in chat, then is referenced in email, then appears in a calendar invite, is one intent — surfaced three times — not three. Deduplication runs on the candidate-task queue before anything is presented for review.

The practical implication: the more surfaces you connect, the better the agent gets at resolving ambiguous commitments. A 'we should look at the Q3 numbers' in chat that turns into a calendar invite the next day is a stronger signal than either alone. The agent uses the second appearance to upgrade the first from 'candidate' to 'commitment.'

Surfaces are the inputs. The next lesson is the act of capture itself — how Kavanah turns a candidate from one of these surfaces into a triaged, owned, estimated task.