Module 1 — Foundations · Lesson 1.4
Setting Up a Kavanah Workspace with Intention
The first ten minutes — and what to do in them
~13 min
What you'll learn
- Set up a workspace whose structure encodes how the team actually works
- Decide what becomes a project versus a label versus a tag
- Seed the skills vocabulary so capability-aware assignment works on day one
- Pick the right first integration to connect, and why
Most teams treat the first ten minutes inside a new tool as configuration. We are going to treat them as an act of management. The choices you make in setup encode assumptions about how the team works, what counts as a project, who is responsible for what, and what the AI agent gets to act on. Those assumptions then quietly govern the next year of work — usually invisibly. Make them deliberately.
The minimum viable charter
Before you create projects, write a minimum viable workspace charter. Three sentences. One for K, one for V, one for N.
Know-How: 'In this workspace, work generally requires familiarity with X, Y, and access to Z.' This becomes the default capability assumption the AI agent uses when triaging tasks.
Vision: 'This workspace exists to ship X for Y customer.' This becomes the lens every project charter inherits.
Negation: 'We do not do A, B, or C, no matter how appealing.' This becomes the rule the AI agent applies before turning any conversation into a task.
It does not have to be perfect. It has to exist. A bad charter you can edit is worth ten quarters of a charter you intended to write next week.
What becomes a project (and what does not)
Projects are the unit of charter and assignment. The temptation in a new workspace is to make everything a project — including ongoing operations, support queues, and personal initiatives. Resist it. A project should have a Vision specific enough that you could write a one-paragraph close-out memo when it ends. If a piece of work has no end state — 'support tickets,' 'continuous improvement,' 'ongoing maintenance' — it is not a project. It is operations, and it lives in a different surface (the Inbox, recurring tasks, or a knowledge surface).
The right starting set is usually three to six projects. One is current-quarter delivery. One is the most important strategic bet. One or two are customer-facing commitments with clear deadlines. Optionally one is an internal investment (tooling, hiring, infra) with a visible end-state. More than six projects on day one is a signal that the workspace's Vision has not yet been articulated specifically enough — too many things are competing for top-tier attention.
For each project, give it a one-sentence Vision in the charter and at least one Negation. The charter does not have to be done before you create tasks under the project — but it has to exist before the project has been running for a week. Otherwise the project will inherit ambient assumptions, not chosen ones.
Members and skills
Invite the team. As you do, ask each member to declare their skills — at minimum, three. Kavanah's skill vocabulary is fixed (the nine canonical skills) so that the routing and recommendation systems work consistently across workspaces. The declaration carries a proficiency level: Learning, Proficient, or Expert.
The natural objection is 'I do not want to label people.' Treat this as the wrong objection. Without declared skills, the system has nothing to route by, so it cannot recommend assignees, and you fall back to whatever pattern of assignment your team had before — which is usually 'whoever spoke last.' Declared skills also seed the reinforcement loop: when a member ships a task tagged with a skill, their strength on that skill ticks up, which gives the next router slightly better information. The system gets smarter as the team works.
If you only do one thing here, make sure each member has named the one skill they want to be known for. That alone is enough to break the 'whoever spoke last' pattern.
Integrations — pick the one with the most lossy capture
Integrations are how conversations become tasks. The default impulse is to connect everything. Resist it. Connect the surface where your team currently loses the most work between the meeting and the doing.
For most knowledge-work teams, that is email — usually Gmail or ProtonMail. For engineering teams it is GitHub plus your chat surface. For agency teams it is the client portal plus email. For sales-heavy teams it is CRM plus email. Pick the one with the highest 'lossy capture' rate — the place where a conversation generates a commitment that then has to be re-typed into a task by hand.
Once connected, the AI agent can read conversations on that surface (with permission) and propose tasks. Module 2 walks the mechanics. For now, the point is to make one integration live before you do anything else, so the second your team has its first meeting in the new workspace, the capture loop is already closed.
Your first AI Employee
Kavanah ships with a default AI agent every member can chat with. You can also create AI Employees: personas with a name, a personality, a scope of capabilities, and an optional ACL of who can chat with them. The temptation is to skip this on day one. Skip it for the first week. By week two, create exactly one AI Employee — the one whose job is most clearly automatable on your team.
The two most common first AI Employees are a triage assistant (scope: tasks, communications) and a research assistant (scope: knowledge, email, communications). Both have one thing in common: their job description is bounded. The persona, scopes, and member ACL turn into the AI Employee's KVN: K = the scopes it can act in, V = the personality block describing its job, N = the scopes you withheld. Module 3 covers the design of AI Employees in detail.
Set up the workspace deliberately
- 1
Write the three-sentence workspace charter
Open /workspace-kvn and fill all three axes with one sentence each. Do not overthink. You will edit it once you see it in use.
- 2
Each with a one-sentence Vision. No more than six. If you want more, your workspace Vision is not yet specific enough.
- 3
Invite members and have each declare three skills
Use /people. The declaration takes thirty seconds and unlocks routing for the rest of the course.
- 4
Connect one integration — the one with the most lossy capture
Open /settings → Integrations. Pick the surface where your team currently loses the most work between conversation and tracked task.
Setup health checks
- Charter completeness
- Workspace KVN has all three axes filled, plus every active project has at least one Vision.
- Healthy signal: 100% at end of week one. If not, the workspace is running on undocumented assumptions.
- Skill declaration coverage
- Fraction of active members who have declared at least three skills.
- Healthy signal: Above 90% by week two. Below 50% means the routing systems will fall back to defaults.
- Active integration count
- Number of connected integrations actively syncing.
- Healthy signal: One in week one. Resist adding more until you have used the first one for a sprint.
Key takeaways
- ·Setup choices are management choices in disguise.
- ·Write a three-sentence workspace charter first. Edit it after, not instead.
- ·Three to six projects, each with a Vision. Operations is not a project.
- ·Each member declares at least three skills. Without this the router has nothing to route by.
- ·Connect one integration first — the surface where you lose the most work between conversation and task.
With the workspace shaped, the next module turns to the highest-leverage thing Kavanah does on your behalf: turning the conversations your team has every day into the tasks your team should be working on.