Pulse — Internal Communications Agent¶

Thinklio Built-in Agent Specification Version 0.2 | March 2026

1. Purpose and Problem Statement¶

Pulse is the internal communications layer for Thinklio. It handles messaging between users within a workspace, and between agents and users — all within a single, coherent interface governed by an attention management philosophy.

The founding principle: communication should be quiet by default and surface what actually matters.

Most messaging tools are designed to demand attention continuously. Every message arrives as an interruption. The cognitive cost is real — context switching, notification fatigue, the pressure to respond immediately. Pulse is designed to work the other way. Messages arrive silently. The AI scores each one for attention urgency. Only what genuinely warrants interruption breaks through. Everything else is accessible when the user chooses to engage.

This is not a limitation — it is the product. Users who want to think deeply, work without interruption, or manage their communication on their own terms get that by default. Users who prefer more active communication can adjust their settings. The architecture serves different working styles rather than imposing one.

The second founding principle: agents are first-class message participants.

Agents can already respond to users through the chat interface — users go to an agent and ask it things. Pulse adds the complementary capability: agents can come to users, through the same channel as human colleagues. An agent completing a long-running job, a monitor detecting an important signal, a colleague's agent responding to a query — all arrive as messages in Pulse. The user's AI scores all of them for attention the same way, regardless of whether the sender is human or agent.

This opens up workflow flexibility that the platform would otherwise lack. Users who prefer to manage their Thinklio experience through messaging rather than through the chat interface can do so. Users who want their agents to communicate with them in the same place their team communicates with them can do so. The architecture supports different preferences without privileging any single pattern.

2. Attention Management Model¶

Every message that arrives in Pulse is assigned an attention score — a rating of how urgently it warrants the user's conscious engagement.

2.1 Attention Score¶

AttentionScore
├── level       enum (interrupt | surface | available | silent)
├── reason      string (why this score was assigned)
└── expires_at  timestamp | null (after which the score may be re-evaluated)

Level	Meaning	Default behaviour
`interrupt`	Requires the user's attention now	Push notification; appears at top of queue
`surface`	Worth seeing soon, but not urgent	Shown prominently on next Pulse open; no push
`available`	Accessible when the user chooses to look	In the thread, no prominence; no notification
`silent`	Background information; no action needed	Archived immediately; accessible via search

2.2 Scoring Factors¶

The AI scores each incoming message using:

Factor	Weight	Description
Sender relationship	High	Direct reports, manager, close collaborators score higher
Explicit mention	High	@mention or addressed directly to the user
Content urgency signals	High	Deadline language, urgent keywords, questions requiring a decision
Sender type	Medium	Human colleagues score higher than agents by default (configurable)
Thread context	Medium	Active threads the user is engaged in score higher
Time sensitivity	Medium	Messages referencing imminent events
User history	Medium	Topics the user typically responds to quickly
Time of day	Low	Respects focus hours and quiet hours settings
Message volume	Low	High-volume senders are down-weighted over time

Scores are recalculated if context changes — a message scored available can be promoted to interrupt if a subsequent message in the same thread raises urgency.

2.3 User Override¶

Attention scores are AI suggestions, not constraints. Users can: - Manually promote or demote any message's score - Mark specific senders as always interrupt or always silent - Temporarily silence all messages below a threshold (focus mode) - Review the AI's reasoning for any score

The AI learns from user overrides over time — if a user consistently promotes a certain sender from surface to interrupt, the model adjusts for that sender.

3. Thread Types¶

3.1 Human-to-Human Thread¶

Direct or group conversation between workspace users. Conventional direct messaging with attention scoring applied on the recipient side. The AI's role is scoring and optionally assisting with drafting.

3.2 Agent Thread¶

A persistent thread between a user and a specific agent. Unlike the chat interface (which is session-based), an agent thread is continuous — the agent can post to it whenever it has something worth surfacing, and the user can reply directly.

Agent threads are the mechanism for agents to initiate communication. Appropriate uses:

A Research Agent completing a deferred job posts its results
A Monitor Agent detecting a triggered condition posts an alert
The Personal Assistant proactively posts the morning briefing
The Enquiry Agent notifies the user of a new high-priority Item
A colleague's agent responds to a query on their behalf

Every agent the user interacts with can have a persistent thread. Threads for less active agents stay quiet — the attention model ensures this.

3.3 Hybrid Thread¶

A thread with both human and agent participants. Used when a conversation naturally involves both:

A project thread where the Project Coordinator agent participates alongside team members, posting status updates and flagging blockers
A support thread where the Enquiry Agent posts new Items and human team members respond
A broadcast thread where an admin posts an announcement and agents can respond on behalf of recipients

Agent-sent messages in hybrid threads are always visually distinguished. A message from the Project Coordinator agent shows as "Project Coordinator" with an agent icon; a message from a colleague's personal agent shows as "[Name]'s agent."

4. Agents as Message Senders¶

Any agent in the Thinklio platform can send a message to a Pulse thread, subject to the following rules:

The agent must have a configured relationship with the recipient. Agents can message users they are assigned to, or users who are members of a team the agent is assigned to. Agents cannot cold-message users they have no connection to.

The message carries a declared intent. Agent messages carry a structured intent field (alert, result, update, question, response) used by the attention scoring model and displayed as context in the UI.

Frequency limits apply. A configurable per-agent message frequency limit prevents agents becoming noise sources. The default is conservative.

The user controls which agents can message them. In the Agent tab, users allow or block specific agents. By default: agents assigned directly to the user can post; team-level agents can post; org-level agents cannot post without explicit permission.

5. Workflow Preferences¶

Different users work differently. Pulse accommodates this through configurable workflow preferences.

5.1 Preference Profiles¶

Chat-first: The user primarily uses the chat interface for agent interaction. Pulse handles human communications and critical agent alerts only. Agent threads exist but are scored conservatively.

Message-first: The user manages everything through Pulse — agent results, colleague messages, and task notifications all arrive here. The attention model prevents this from becoming overwhelming.

Async-first: The user wants long stretches of uninterrupted time. Only interrupt-level messages surface during focus hours. Everything else accumulates silently and is reviewed in a batch at configured times.

Email-first: The user prefers email as their primary surface. Pulse is used only for urgent real-time communication. Non-urgent messages route to email via the Mail Agent.

These profiles are starting points, not fixed modes. Every setting can be customised individually.

5.2 Focus Modes¶

Focus modes temporarily override the standard attention model:

Mode	Effect	Typical use
Deep work	Only `interrupt` messages surface; all others held	Writing, complex analysis
Meeting	All messages held silently until mode ends	Back-to-back meetings
Offline	No messages delivered; queue held for return	Travel, genuine offline time
Catch-up	All held messages surface at once	Returning from offline period

Focus modes can be set manually, scheduled, or triggered automatically by the Calendar Agent when a meeting begins.

6. Presence¶

Presence is real-time availability information — a live signal of whether the user is engaged.

State	Source	Meaning
Active	Automatic (recent platform activity)	User is in the platform and responsive
Idle	Automatic (no activity for N minutes)	User may be present but not engaged
Focus	Manual or Calendar Agent trigger	Present but not accepting interruptions
Away	Manual	Not at their desk
Agent-only	Manual	User's agent is responding; user is not available
Offline	Automatic (no platform connection)	Not connected

Presence is implemented as a real-time signal via Supabase Realtime subscriptions on a presence table. It reflects actual platform connection and interaction state — not AI inference. Where a user has multiple sessions (devices or tabs), the most active session determines the presence state.

Presence is visible to workspace members in the People tab and alongside sender names in threads. Users can configure visibility scope (all workspace / team only).

7. UI Structure¶

[ Chat ]  [ Threads ]  [ People ]  [ Agent ]

Chat Tab¶

The active conversation view. All thread types — human-to-human, agent thread, hybrid — use the same interface, with sender type indicated visually on each message. A context bar above the thread shows participants with presence indicators and any active agent in the thread.

Suggested replies appear below the compose field, not pre-filled — the user actively selects them rather than having text injected into their compose field.

Threads Tab¶

The message queue — threads sorted by attention score then recency. This is not a chronological feed.

Grouped by attention level: - Needs attention (interrupt) — shown prominently at top - When you're ready (surface) — clearly delineated below - Background (available and silent) — collapsed by default, expandable

This visual grouping is the core of the attention surfacing experience.

People Tab¶

Workspace directory with real-time presence indicators. Each person shows: name, role, team, presence state, agent availability, and message / ask-their-agent actions.

Agent Tab¶

Personal Pulse configuration:

Attention settings: Sender overrides, focus mode schedule, push notification threshold, quiet hours.

Workflow preferences: Profile selection, focus mode triggers, message routing rules.

Agent messaging permissions: Which agents can post to threads, per-agent frequency limits, routing preferences (Pulse vs. email vs. notification only).

Proxy settings: Enable/disable proxy mode, topics the agent may respond to, activation conditions, knowledge sharing permissions.

8. Inter-Agent Behaviour¶

Agent	Relationship
Personal Assistant	Primary source of proxy and assist mode intelligence in Pulse
Messenger Agent	Handles external platforms. A unified attention queue spanning both internal and external messaging is a natural future capability
Calendar Agent	Triggers focus modes on meeting events; feeds time context into attention scoring
Taskmaster	Pulse threads generate tasks; task due dates feed into attention scoring
Monitor Agent	Posts alerts to agent threads; `interrupt` intent by default for triggered conditions
Enquiry Agent	Posts new high-priority Item assignments to relevant users
Mail Agent	Routes non-urgent Pulse messages to email for email-first users; replies flow back

9. Data Model¶

Thread
├── thread_id           UUID
├── type                enum (human | agent | hybrid)
├── name                string | null
├── created_by_type     enum (user | agent)
├── created_by_id       UUID
├── created_at          timestamp
└── participants[]      ThreadParticipant[]

ThreadParticipant
├── thread_id           UUID
├── participant_type    enum (user | agent)
├── participant_id      UUID
├── joined_at           timestamp
└── last_read_at        timestamp | null

Message
├── message_id          UUID
├── thread_id           UUID
├── sender_type         enum (user | agent)
├── sender_id           UUID
├── on_behalf_of        UUID | null (user_id if agent is acting as proxy)
├── content             string
├── intent              enum (message | alert | result | update | question | response) | null
├── attention_score     enum (interrupt | surface | available | silent)
├── attention_reason    string | null
├── sent_at             timestamp
└── edited_at           timestamp | null

UserPresence
├── user_id             UUID
├── state               enum (active | idle | focus | away | agent_only | offline)
├── state_since         timestamp
├── state_until         timestamp | null
└── updated_at          timestamp

UserPulsePreferences
├── user_id             UUID
├── workflow_profile    enum (chat_first | message_first | async_first | email_first)
├── push_threshold      enum (interrupt | surface | all)
├── quiet_hours_start   time | null
├── quiet_hours_end     time | null
├── sender_overrides    JSONB
├── agent_permissions   JSONB
└── proxy_config        JSONB

10. Use Cases¶

UC-1: Uninterrupted deep work¶

A user spends two hours writing. No notifications arrive. When they open Pulse: one thread in "Needs attention" (a team lead asking for a decision), three threads in "When you're ready" (a routine question, a resolved Monitor alert, and a completed Research Agent briefing). The user handles what matters first. They never felt the other messages arrive.

UC-2: Agent result via thread¶

A user kicked off a research job yesterday. Their workflow preference is message-first. Rather than checking the chat interface, the Briefing Agent posts to their agent thread when complete: "Your briefing on aged care regulatory changes is ready. [Preview] [Open full briefing]." Scored surface — it waits in "When you're ready."

UC-3: Colleague's agent responding¶

User A asks User B's status on a deployment. User B is in Agent-only mode. User B's PA responds from its knowledge: "Sam's agent: The deployment is staged and ready. Sam was planning to go live after the 3pm review. No blockers as of this morning." User A gets a useful answer without interrupting User B.

UC-4: Project hybrid thread¶

A project team thread includes the Project Coordinator agent alongside team members. During the week, the agent posts daily summaries: task completion, blockers, upcoming milestones. Summaries are scored available — informative, no action required. When a blocker needs human attention, the agent posts with interrupt intent and the message surfaces immediately.

UC-5: Focus mode from calendar¶

A user's calendar has a two-hour block labelled "Deep work." The Calendar Agent activates Focus mode automatically at the start. During those two hours, 11 messages arrive — only one scores interrupt (a direct question from the CEO about a deadline). The rest queue silently. At the end of the block, the user gets a catch-up summary: "11 messages while you were in focus. 1 needed attention — you saw it. 10 are waiting when you're ready."

11. Open Questions¶

Should attention score be visible to the message sender? Transparency argues for it; gaming the model (flooding messages with urgency language) argues against.
The unified attention queue spanning Pulse and Messenger Agent (internal + external) is the natural evolution. What triggers that integration — user opt-in, or automatic once both agents are configured?
Persistent agent threads accumulate over time into a meaningful record of agent activity. What is the retention policy, and can users export or search this history?
The attention scoring model learns from user overrides. This learning lives in the user knowledge layer and must not influence scoring for other users. This is structurally guaranteed by the knowledge model but worth explicitly confirming in the platform security review.
For the proxy model: should there be a way for User A to know, before sending, whether User B's agent is available to respond? Showing this in the People tab (alongside presence) would help set communication expectations.

Previous: Foundational Chat Agent | See also: Messenger Agent (external platforms), Personal Assistant (proxy mode)