Rowboat Feature Adoption Plan

Document Version: 1.0 Created: February 2026 Source Repository: github.com/rowboatlabs/rowboat Status: Proposed

Executive Summary

This document outlines strategic feature adoptions from the Rowboat AI assistant platform that would significantly enhance Consul Agent's value proposition. After comprehensive analysis of both codebases, we've identified 10 high-impact opportunities that leverage Consul's existing infrastructure while addressing current gaps in intelligence amplification.

The recommended adoptions focus on making Consul smarter about user context rather than adding new integrations. The existing tool ecosystem (100+ tools), workflow infrastructure, and three-tier memory system provide a strong foundation—the opportunity is using data we already capture more intelligently.

Key Themes:

Transform passive data collection into active relationship intelligence
Surface the "why" behind agent decisions to build user trust
Enable cross-conversation learning that compounds over time
Prepare users for meetings with contextual briefings

Analysis Methodology
Current State Assessment
Feature Recommendations
Implementation Roadmap
Technical Dependencies
Success Metrics
Risk Assessment
Appendix: Rowboat Architecture Overview

Analysis Methodology

Repositories Analyzed

Repository	Description	Key Strengths
rowboat	Desktop AI coworker with persistent memory	Knowledge graph, entity extraction, event-sourced execution
consul-agent	Executive AI assistant with Google Workspace integration	Mature tool ecosystem, multi-channel delivery, workflow automation

Evaluation Criteria

Each feature was evaluated on:

User Value — Direct impact on user productivity/experience
Technical Fit — Compatibility with existing architecture
Implementation Effort — Engineering resources required
Strategic Alignment — Fit with Consul's product vision

Current State Assessment

Consul Agent Strengths

Category	Status	Details
Tool Ecosystem	✅ Strong	100+ tools across Gmail, Calendar, Drive, Docs, Slack, Contacts
Workflow Automation	✅ Strong	Email triage, daily briefs, scheduling, sales processing
Multi-Channel	✅ Strong	Web chat, iMessage/SMS, Email (AgentMail)
Memory System	✅ Strong	Working + Semantic + Observational memory tiers
Safety Controls	✅ Strong	14-stage processor pipeline, human-in-the-loop confirmation

Identified Gaps

Gap	Current State	Impact
Entity Extraction	Manual relationship entry only	Users must explicitly tell Consul about contacts
Meeting Preparation	Daily brief lists meetings, no attendee context	Missed opportunity for high-value briefings
Decision Transparency	Shows what action, not why	Reduces user trust and adoption
Relationship Utilization	`relationships` table exists but unused in tools	Drafts lack personalization context
Cross-Tool Learning	Tools operate independently	Preferences not shared across tool executions
Skill Analytics	On/off toggle only	No visibility into automation effectiveness

Feature Recommendations

Tier 1: Highest Impact

These features address critical gaps with immediate, visible user value.

1. Knowledge Graph & Entity Extraction

Priority: P0 — Critical Effort: Medium (3-4 weeks) User Value: High

What Rowboat Has

Rowboat automatically extracts entities (people, organizations, projects, topics) from:

Emails and attachments
Meeting transcripts
Voice memos
Notes

Entities are linked in a knowledge graph with relationship types and interaction history.

Current Gap in Consul

The relationships table exists but requires manual population. The agent processes thousands of emails but doesn't learn who matters from communication patterns.

Proposed Implementation

┌─────────────────────────────────────────────────────────────┐
│                    Entity Extraction Pipeline               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  emailTriageWorkflow ──► extractEntitiesStep ──► Supabase  │
│                              │                              │
│  dailyBriefWorkflow ──► extractEntitiesStep ──► Supabase  │
│                              │                              │
│  (future) meetingNotes ──► extractEntitiesStep ──► Supabase│
│                                                             │
└─────────────────────────────────────────────────────────────┘

New Database Tables:

-- Extracted entities from communications
CREATE TABLE entities (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES profiles(id),
  entity_type TEXT NOT NULL, -- 'person', 'organization', 'project', 'topic'
  name TEXT NOT NULL,
  aliases TEXT[], -- Alternative names/spellings
  email TEXT, -- For person entities
  metadata JSONB DEFAULT '{}',
  first_seen TIMESTAMPTZ DEFAULT now(),
  last_seen TIMESTAMPTZ DEFAULT now(),
  mention_count INTEGER DEFAULT 1,
  UNIQUE(user_id, entity_type, name)
);

-- Relationships between entities
CREATE TABLE entity_relationships (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES profiles(id),
  source_entity_id UUID NOT NULL REFERENCES entities(id),
  target_entity_id UUID NOT NULL REFERENCES entities(id),
  relationship_type TEXT NOT NULL, -- 'works_with', 'reports_to', 'collaborates_on'
  strength REAL DEFAULT 0.5, -- 0-1 based on interaction frequency
  last_interaction TIMESTAMPTZ,
  context TEXT -- e.g., "Frequently CC'd together on legal emails"
);

-- Entity mentions in communications
CREATE TABLE entity_mentions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  entity_id UUID NOT NULL REFERENCES entities(id),
  source_type TEXT NOT NULL, -- 'email', 'calendar', 'note'
  source_id TEXT NOT NULL, -- Gmail message ID, calendar event ID, etc.
  mentioned_at TIMESTAMPTZ DEFAULT now(),
  context_snippet TEXT -- Surrounding text for context
);

New Workflow Step:

// apps/agents/src/mastra/workflows/steps/extract-entities.ts
export const extractEntitiesStep = createStep({
  id: "extract-entities",
  inputSchema: z.object({
    content: z.string(),
    sourceType: z.enum(["email", "calendar", "note"]),
    sourceId: z.string(),
    userId: z.string(),
  }),
  outputSchema: z.object({
    entities: z.array(z.object({
      type: z.enum(["person", "organization", "project", "topic"]),
      name: z.string(),
      email: z.string().optional(),
      confidence: z.number(),
    })),
  }),
  execute: async ({ inputData, mastra }) => {
    const model = mastra.getModel("openai/gpt-4.1-mini");

    const result = await model.generate({
      messages: [{
        role: "system",
        content: ENTITY_EXTRACTION_PROMPT,
      }, {
        role: "user",
        content: inputData.content,
      }],
      response_format: { type: "json_object" },
    });

    // Upsert entities to Supabase
    // Link to source via entity_mentions
    // Update relationship strengths based on co-occurrence

    return { entities: result.entities };
  },
});

Success Metrics

Entities extracted per user per week
Relationship accuracy (user corrections)
Entity utilization rate in drafting/scheduling

2. Meeting Prep Agent

Priority: P0 — Critical Effort: Medium (2-3 weeks) User Value: Very High

What Rowboat Has

Pre-meeting briefings that include:

Attendee backgrounds and roles
Recent interaction history
Open threads/action items with each attendee
Suggested talking points
Relevant documents/emails

Current Gap in Consul

Daily brief lists upcoming meetings but provides no attendee context. Users enter meetings without knowing what was last discussed or what's pending with each participant.

Proposed Implementation

Option A: Extend Daily Brief Add a meetingPrepSection to dailyBriefWorkflow that generates per-meeting briefings.

Option B: Standalone Workflow (Recommended) Create meetingPrepWorkflow that runs 30 minutes before each meeting, delivering briefing via preferred channel.

┌─────────────────────────────────────────────────────────────┐
│                   Meeting Prep Workflow                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. fetchUpcomingMeetings (next 2 hours)                   │
│           │                                                 │
│           ▼                                                 │
│  2. For each meeting:                                       │
│     ├─ resolveAttendees (→ entities table)                 │
│     ├─ fetchRecentEmails (with each attendee)              │
│     ├─ fetchPastMeetings (with same attendees)             │
│     ├─ fetchOpenReminders (related to attendees)           │
│     └─ fetchRelatedDocs (shared recently)                  │
│           │                                                 │
│           ▼                                                 │
│  3. generateBriefing (structured summary)                  │
│           │                                                 │
│           ▼                                                 │
│  4. deliverBriefing (iMessage/email/web notification)      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Briefing Output Schema:

const meetingBriefingSchema = z.object({
  meetingTitle: z.string(),
  startTime: z.string(),
  attendees: z.array(z.object({
    name: z.string(),
    email: z.string(),
    role: z.string().optional(),
    relationship: z.string().optional(), // From relationships table
    lastInteraction: z.object({
      date: z.string(),
      summary: z.string(),
    }).optional(),
    openItems: z.array(z.string()), // Pending actions/reminders
  })),
  suggestedAgenda: z.array(z.string()),
  relevantContext: z.array(z.object({
    type: z.enum(["email", "document", "reminder"]),
    title: z.string(),
    summary: z.string(),
    link: z.string().optional(),
  })),
  talkingPoints: z.array(z.string()),
});

Success Metrics

Meeting prep delivery rate (% of meetings with briefing)
User engagement (opened, actioned)
Feedback rating (thumbs up/down on briefings)

3. Decision Reasoning Transparency

Priority: P0 — Critical Effort: Low (1-2 weeks) User Value: High

What Rowboat Has

Event-sourced execution with full audit trail. Users can see the chain of reasoning that led to any action.

Current Gap in Consul

The suspend/resume pattern shows what action the agent wants to take but not why it chose that action over alternatives.

Proposed Implementation

Schema Changes:

-- Add reasoning to pending_approvals
ALTER TABLE pending_approvals
ADD COLUMN reasoning TEXT,
ADD COLUMN alternatives_considered JSONB DEFAULT '[]',
ADD COLUMN confidence REAL;

Tool Output Enhancement:

// Extend tool output schema pattern
const toolOutputWithReasoning = baseOutputSchema.extend({
  _reasoning: z.object({
    rationale: z.string(),
    alternativesConsidered: z.array(z.object({
      action: z.string(),
      whyNotChosen: z.string(),
    })).optional(),
    confidence: z.number().min(0).max(1),
    dataSourcesUsed: z.array(z.string()),
  }).optional(),
});

Processor Enhancement:

Create ReasoningCaptureProcessor that extracts reasoning from tool calls and stores it:

export class ReasoningCaptureProcessor extends InputProcessor {
  async process(messages: Message[]): Promise<Message[]> {
    // After tool execution, capture reasoning from assistant message
    // Store in pending_approvals.reasoning for suspended tools
    // Log to decision_audit_log for all tools
    return messages;
  }
}

UI Enhancement:

Update confirmation modal to display:

"Why this action?" expandable section
Alternatives considered (if any)
Confidence indicator
Data sources referenced

Success Metrics

Confirmation acceptance rate (should increase with transparency)
Time-to-decision (should decrease as users trust reasoning)
User feedback on reasoning quality

Tier 2: High Impact

Significant value with moderate architectural work.

4. Cross-Conversation Learning

Priority: P1 — High Effort: Medium (2-3 weeks) User Value: High

What Rowboat Has

Knowledge index that refreshes between processing batches. Entities and patterns learned in one context are available in all future contexts.

Current Gap in Consul

ObservationalMemory exists but tools don't actively share learnings. Each tool operates with local context only.

Proposed Implementation

Observation Emission Pattern:

// After successful tool execution, emit observation
export async function emitObservation(
  context: ToolContext,
  observation: {
    type: 'preference' | 'pattern' | 'correction' | 'feedback';
    category: string; // e.g., 'scheduling', 'email_tone', 'meeting_duration'
    content: string;
    confidence: number;
    source: string; // Tool ID that generated observation
  }
) {
  const userId = context.requestContext?.get("userId");
  if (!userId) return;

  // Store in observations table
  await supabase.from("user_observations").insert({
    user_id: userId,
    ...observation,
    observed_at: new Date().toISOString(),
  });

  // Update working memory with high-confidence observations
  if (observation.confidence > 0.8) {
    // Merge into working memory schema
  }
}

Example Observations:

Tool	Observation Type	Example
`scheduleMeeting`	preference	"User prefers 30-minute meetings over 1-hour"
`composeEmail`	pattern	"User always includes greeting before business content"
`triageEmail`	pattern	"User archives all marketing emails from @promotions.com"
`confirmSendEmail`	correction	"User edited draft to add CC — remember to include Jane on legal emails"

Observation Retrieval:

Tools query relevant observations before execution:

const relevantObservations = await getObservations({
  userId,
  categories: ["email_tone", "recipient_preferences"],
  minConfidence: 0.7,
  limit: 5,
});

// Include in tool context for LLM

Success Metrics

Observations generated per user per week
Observation accuracy (validated by user corrections)
Reduced user edits to agent-generated content

5. Relationship-Aware Drafting

Priority: P1 — High Effort: Low (1 week) User Value: High

What Rowboat Has

Wiki-style links to people entities. Drafting tools pull relationship context automatically.

Current Gap in Consul

The relationships table exists with contact tags and notes, but composeEmail and triage draft tools don't query it.

Proposed Implementation

Enhance composeEmail and Related Tools:

// In composeEmail execute function
const recipientContext = await getRelationshipContext(userId, recipientEmail);

// recipientContext includes:
// - relationship tags (e.g., "client", "team member", "executive")
// - last interaction date and summary
// - communication style notes
// - preferred formality level
// - any user notes about the relationship

// Include in LLM prompt
const systemPrompt = `
You are drafting an email to ${recipientContext.name}.

Relationship context:
- Type: ${recipientContext.tags.join(", ")}
- Last interaction: ${recipientContext.lastInteraction}
- Communication style: ${recipientContext.communicationStyle}
- User notes: ${recipientContext.notes}

Adjust tone and content appropriately.
`;

Relationship Context Query:

async function getRelationshipContext(
  userId: string,
  email: string
): Promise<RelationshipContext | null> {
  // Check relationships table
  const relationship = await supabase
    .from("relationships")
    .select("*")
    .eq("user_id", userId)
    .eq("email", email)
    .single();

  if (relationship) {
    return {
      name: relationship.name,
      tags: relationship.tags,
      notes: relationship.notes,
      lastInteraction: relationship.last_interaction_at,
      communicationStyle: relationship.communication_style,
    };
  }

  // Fall back to entities table if no explicit relationship
  const entity = await supabase
    .from("entities")
    .select("*")
    .eq("user_id", userId)
    .eq("email", email)
    .single();

  return entity ? mapEntityToContext(entity) : null;
}

Success Metrics

Draft acceptance rate (should increase)
User edits per draft (should decrease)
Relationship data utilization rate

6. Skill Performance Analytics

Priority: P1 — High Effort: Medium (2-3 weeks) User Value: Medium-High

What Rowboat Has

PostHog integration with detailed event tracking. Users can see which features work well.

Current Gap in Consul

Skills (triage, drafting, scheduling, etc.) have on/off toggles but no metrics on effectiveness.

Proposed Implementation

New Analytics Tables:

CREATE TABLE skill_events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES profiles(id),
  skill_id TEXT NOT NULL, -- 'triage', 'drafting', 'scheduling', etc.
  event_type TEXT NOT NULL, -- 'invoked', 'completed', 'failed', 'approved', 'rejected', 'edited'
  metadata JSONB DEFAULT '{}',
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE skill_metrics (
  user_id UUID NOT NULL REFERENCES profiles(id),
  skill_id TEXT NOT NULL,
  period_start DATE NOT NULL,
  invocation_count INTEGER DEFAULT 0,
  success_count INTEGER DEFAULT 0,
  failure_count INTEGER DEFAULT 0,
  approval_rate REAL, -- For skills with confirmation
  avg_time_to_completion INTERVAL,
  user_edit_rate REAL, -- How often user modified output
  PRIMARY KEY (user_id, skill_id, period_start)
);

Dashboard Component:

// apps/web/app/(authenticated)/skills/[skillId]/analytics/page.tsx
export default function SkillAnalyticsPage({ params }: { params: { skillId: string } }) {
  return (
    <div className="space-y-6">
      <SkillMetricsSummary skillId={params.skillId} />
      <SkillTrendChart skillId={params.skillId} period="30d" />
      <SkillEventLog skillId={params.skillId} limit={50} />
      <SkillRecommendations skillId={params.skillId} />
    </div>
  );
}

Metrics Displayed:

Invocations per day/week
Success rate trend
Approval vs. rejection rate (for confirmable actions)
Average time to user decision
Common failure reasons
Recommendations for improvement

Success Metrics

User engagement with analytics pages
Skill configuration changes after viewing analytics
Overall skill effectiveness improvements

Tier 3: Medium Impact

Valuable features with higher implementation effort.

7. Voice Memos with Transcription

Priority: P2 — Medium Effort: Medium-High (3-4 weeks) User Value: Medium-High

What Rowboat Has

Voice recording with Deepgram transcription. Voice notes become searchable knowledge.

Proposed Implementation

Frontend (Web):

// apps/web/components/chat/voice-input.tsx
export function VoiceInput({ onTranscription }: { onTranscription: (text: string) => void }) {
  const [isRecording, setIsRecording] = useState(false);
  const mediaRecorder = useRef<MediaRecorder | null>(null);

  const startRecording = async () => {
    const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
    mediaRecorder.current = new MediaRecorder(stream);
    // ... capture audio chunks
  };

  const stopAndTranscribe = async () => {
    const audioBlob = new Blob(chunks, { type: "audio/webm" });
    const formData = new FormData();
    formData.append("audio", audioBlob);

    const response = await fetch("/api/transcribe", {
      method: "POST",
      body: formData,
    });

    const { text } = await response.json();
    onTranscription(text);
  };

  return (
    <Button
      variant={isRecording ? "destructive" : "outline"}
      onClick={isRecording ? stopAndTranscribe : startRecording}
    >
      <Mic className="h-4 w-4" />
    </Button>
  );
}

Backend Transcription:

// apps/web/app/api/transcribe/route.ts
export async function POST(request: Request) {
  const formData = await request.formData();
  const audioFile = formData.get("audio") as File;

  const transcription = await openai.audio.transcriptions.create({
    file: audioFile,
    model: "whisper-1",
  });

  return NextResponse.json({ text: transcription.text });
}

Success Metrics

Voice input usage rate
Transcription accuracy (user corrections)
Task completion rate via voice vs. text

8. Wiki-Style Knowledge Base

Priority: P2 — Medium Effort: High (4-6 weeks) User Value: Medium

What Rowboat Has

Local markdown files with [[wiki links]]. Graph visualization of knowledge relationships.

Proposed Implementation

Database Schema:

CREATE TABLE notes (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES profiles(id),
  title TEXT NOT NULL,
  content TEXT NOT NULL, -- Markdown with [[wiki links]]
  tags TEXT[] DEFAULT '{}',
  linked_entities UUID[] DEFAULT '{}', -- References to entities table
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE note_links (
  source_note_id UUID NOT NULL REFERENCES notes(id),
  target_note_id UUID NOT NULL REFERENCES notes(id),
  link_text TEXT, -- The [[text]] used
  PRIMARY KEY (source_note_id, target_note_id)
);

New Tools:

createNote — Create new knowledge note
updateNote — Edit existing note
searchNotes — Full-text search across notes
linkNote — Create wiki-style link between notes

UI Components:

Note editor with wiki-link autocomplete
Knowledge graph visualization
Note search and browse interface

Success Metrics

Notes created per user
Wiki links created
Note retrieval in agent conversations

9. MCP (Model Context Protocol) Integration

Priority: P2 — Medium Effort: High (4-6 weeks) User Value: Medium (power users)

What Rowboat Has

Extensible tool system via MCP servers. Users can add custom tool providers.

Proposed Implementation

MCP Client in Agents:

// apps/agents/src/mastra/mcp/client.ts
import { Client } from "@modelcontextprotocol/sdk/client";

export class MCPToolProvider {
  private clients: Map<string, Client> = new Map();

  async connectServer(config: MCPServerConfig): Promise<void> {
    const client = new Client({
      name: "consul-agent",
      version: "1.0.0",
    });

    await client.connect({
      command: config.command,
      args: config.args,
    });

    this.clients.set(config.id, client);
  }

  async getTools(serverId: string): Promise<Tool[]> {
    const client = this.clients.get(serverId);
    if (!client) throw new Error(`MCP server ${serverId} not connected`);

    const { tools } = await client.listTools();
    return tools.map(mcpToolToMastraTool);
  }

  async invokeTool(serverId: string, toolName: string, args: unknown): Promise<unknown> {
    const client = this.clients.get(serverId);
    return client.callTool({ name: toolName, arguments: args });
  }
}

User Configuration UI:

MCP server management page
Add/remove server configurations
Test connection functionality
Per-server tool visibility settings

Success Metrics

MCP servers configured per user
MCP tool invocations
Custom integration adoption

Tier 4: Lower Priority

Interesting capabilities for future consideration.

10. Composio Integration

Priority: P3 — Low Effort: Medium (2-3 weeks) User Value: Low-Medium

What Rowboat Has

Pre-built connections to 100+ apps via Composio platform.

Proposed Implementation

Integrate Composio SDK for simplified OAuth and third-party tool access. Useful for quickly adding integrations without building custom OAuth flows.

Considerations

Adds external dependency for auth management
May conflict with existing custom OAuth implementations
Best suited if rapidly expanding integration count

Implementation Roadmap

Phase 1: Quick Wins (Weeks 1-4)

Feature	Effort	Dependencies
Decision Reasoning Transparency (#3)	1-2 weeks	None
Relationship-Aware Drafting (#5)	1 week	None
Basic Entity Extraction (#1 partial)	1-2 weeks	None

Deliverables:

Reasoning displayed in confirmation modals
composeEmail queries relationships table
Entity extraction step added to emailTriageWorkflow

Phase 2: Core Intelligence (Weeks 5-12)

Feature	Effort	Dependencies
Meeting Prep Workflow (#2)	2-3 weeks	Entity extraction
Full Knowledge Graph (#1 complete)	2-3 weeks	Phase 1 entity work
Cross-Conversation Learning (#4)	2-3 weeks	None

Deliverables:

meetingPrepWorkflow delivering briefings before meetings
Entities table fully populated from all communication sources
Observations system capturing and applying learnings

Phase 3: Polish & Analytics (Weeks 13-18)

Feature	Effort	Dependencies
Skill Performance Analytics (#6)	2-3 weeks	None
Voice Memos (#7)	3-4 weeks	None

Deliverables:

Analytics dashboard for each skill
Voice input in web chat

Phase 4: Expansion (Future)

Feature	Effort	Dependencies
Wiki-Style Knowledge Base (#8)	4-6 weeks	Entity extraction
MCP Integration (#9)	4-6 weeks	None
Composio Integration (#10)	2-3 weeks	None

Technical Dependencies

New Packages Required

{
  "@modelcontextprotocol/sdk": "^1.0.0", // For MCP integration (Phase 4)
  "deepgram-sdk": "^3.0.0" // Alternative to OpenAI Whisper (Phase 3)
}

Database Migrations Required

Phase	Tables	Description
1	`pending_approvals` (alter)	Add reasoning columns
1-2	`entities`, `entity_relationships`, `entity_mentions`	Knowledge graph
2	`user_observations`	Cross-conversation learning
3	`skill_events`, `skill_metrics`	Analytics
4	`notes`, `note_links`	Wiki knowledge base

Infrastructure Considerations

No new services required for Phases 1-3
Vector database updates may be needed for semantic entity search
Background job capacity — Meeting prep workflow adds scheduled jobs

Success Metrics

User-Facing Metrics

Metric	Baseline	Target	Measurement
Confirmation acceptance rate	65%	85%	pending_approvals accept/reject ratio
Draft edit rate	40%	20%	User modifications to agent drafts
Meeting prep engagement	N/A	70% open rate	Briefing delivery and opens
Time to first action	45s	25s	User decision time on confirmations

System Metrics

Metric	Target	Measurement
Entities extracted/user/week	50+	entities table growth
Observations generated/user/week	20+	user_observations table
Cross-tool learning accuracy	80%+	Observation validation rate

Risk Assessment

Technical Risks

Risk	Likelihood	Impact	Mitigation
Entity extraction accuracy	Medium	Medium	Use confidence thresholds; allow user corrections
Meeting prep timing failures	Low	High	Fallback delivery windows; retry logic
Observation noise	Medium	Low	Confidence filtering; periodic cleanup

Product Risks

Risk	Likelihood	Impact	Mitigation
Information overload (meeting prep)	Medium	Medium	Configurable briefing depth
Privacy concerns (entity tracking)	Low	High	Clear data policies; user controls
Feature complexity	Medium	Medium	Phased rollout; feature flags

Appendix: Rowboat Architecture Overview

Key Architectural Patterns

1. Event-Sourced Agent Execution

Rowboat reconstructs agent state from immutable event logs, enabling:

Resumable runs across sessions
Full audit trail
Time-travel debugging

2. Knowledge Graph Structure

┌─────────────────────────────────────────────────────────────┐
│                     Knowledge Graph                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│    ┌──────────┐         ┌──────────┐         ┌──────────┐  │
│    │  Person  │────────▶│  Project │◀────────│   Topic  │  │
│    └──────────┘         └──────────┘         └──────────┘  │
│         │                    │                     │        │
│         │    ┌───────────────┼───────────────┐    │        │
│         │    │               │               │    │        │
│         ▼    ▼               ▼               ▼    ▼        │
│    ┌──────────┐         ┌──────────┐         ┌──────────┐  │
│    │   Org    │         │  Email   │         │ Meeting  │  │
│    └──────────┘         └──────────┘         └──────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

3. Tiered Note Creation

Rowboat uses complexity-based processing:

High complexity: Full multi-agent analysis
Medium complexity: Single-agent with context
Low complexity: Direct extraction

4. MCP Tool Architecture

┌─────────────────────────────────────────────────────────────┐
│                      Tool System                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │  Built-in   │  │    MCP      │  │  Sub-Agent  │        │
│  │   Tools     │  │   Tools     │  │   Tools     │        │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘        │
│         │                │                │                │
│         └────────────────┼────────────────┘                │
│                          │                                 │
│                          ▼                                 │
│                  ┌──────────────┐                          │
│                  │ Agent Runtime │                          │
│                  └──────────────┘                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Document History

Version	Date	Author	Changes
1.0	Feb 2026	Claude Code	Initial analysis and recommendations

This document should be reviewed and updated as implementation progresses and priorities shift.

Rowboat Feature Adoption Plan

Executive Summary

Table of Contents

Analysis Methodology

Repositories Analyzed

Evaluation Criteria

Current State Assessment

Consul Agent Strengths

Identified Gaps

Feature Recommendations

Tier 1: Highest Impact

1. Knowledge Graph & Entity Extraction

What Rowboat Has

Current Gap in Consul

Proposed Implementation

Success Metrics

2. Meeting Prep Agent

What Rowboat Has

Current Gap in Consul

Proposed Implementation

Success Metrics

3. Decision Reasoning Transparency

What Rowboat Has

Current Gap in Consul

Proposed Implementation

Success Metrics

Tier 2: High Impact

4. Cross-Conversation Learning

What Rowboat Has

Current Gap in Consul

Proposed Implementation

Success Metrics

5. Relationship-Aware Drafting

What Rowboat Has

Current Gap in Consul

Proposed Implementation

Success Metrics

6. Skill Performance Analytics

What Rowboat Has

Current Gap in Consul

Proposed Implementation

Success Metrics

Tier 3: Medium Impact

7. Voice Memos with Transcription

What Rowboat Has

Proposed Implementation

Success Metrics

8. Wiki-Style Knowledge Base

What Rowboat Has

Proposed Implementation

Success Metrics

9. MCP (Model Context Protocol) Integration

What Rowboat Has

Proposed Implementation

Success Metrics

Tier 4: Lower Priority

10. Composio Integration

What Rowboat Has

Proposed Implementation

Considerations

Implementation Roadmap

Phase 1: Quick Wins (Weeks 1-4)

Phase 2: Core Intelligence (Weeks 5-12)

Phase 3: Polish & Analytics (Weeks 13-18)

Phase 4: Expansion (Future)

Technical Dependencies

New Packages Required

Database Migrations Required

Infrastructure Considerations

Success Metrics

User-Facing Metrics

System Metrics

Risk Assessment

Technical Risks

Product Risks

Appendix: Rowboat Architecture Overview

Key Architectural Patterns

Document History