Every engineering team has the same problem. Knowledge lives everywhere and nowhere at once — in Slack threads that scroll away, in Notion docs nobody updates, in the heads of people who quit six months ago. When someone asks “why did we pick PostgreSQL over MySQL?” the answer is a 45-minute archaeology expedition through old PRs and Slack history.

We’ve all tried to fix this. Wikis. Notion. Confluence. Obsidian vaults. The writing is easy. The maintenance is brutal. Pages go stale. Cross-references break. The index becomes a lie. Nobody has time to keep it current, and so slowly, inevitably, it rots.

Kosh is an attempt to solve the maintenance problem — by handing it to an LLM.

The Core Idea

Kosh keeps a structured wiki in Obsidian. When you feed it a document — a design doc, a meeting note, a post-mortem, an ADR — an LLM doesn’t just summarize it. It integrates it:

• Writes a source summary page
• Creates or updates entity pages (people, systems, teams, products)
• Creates or updates concept pages (ideas, patterns, decisions)
• Flags any contradictions with what the wiki already knows
• Updates the index
• Appends a log entry

Every piece of knowledge links to every other relevant piece. The wiki is always a single coherent artifact, not a collection of orphaned docs.

When you ask a question, the LLM reads the relevant pages and synthesizes a cited answer. You can save that answer back to the wiki, where it becomes another page future queries can draw from. The wiki compounds. The more you put in, the richer every answer gets — without increasing the cost of asking.

Why Obsidian?

Obsidian is the right storage layer for a few reasons:

It’s just files. Your wiki is markdown on disk. No vendor lock-in, no proprietary format. You can read it, search it, version-control it, and migrate it with cp.

It has a graph view. After a few weeks of ingestion, you open Ctrl+G and see the shape of your team's knowledge — hubs (well-connected ideas), orphans (stubs that need work), clusters (related concepts that might want a parent page). The structure tells you things.

It has the Local REST API plugin. This is what makes Kosh possible. Kosh talks to Obsidian over a local HTTP API, reading and writing files without touching the filesystem directly. Each vault runs on its own port; Kosh manages all of them from one server.

Multi-Team, Multi-Vault

Kosh is designed for a real team, not a single user.

Each functional team gets its own Obsidian vault. Engineering gets engineering. Strategy gets strategy. The CTO team can edit the engineering vault but only view strategy. The CEO team admins strategy but can read everything. Access is controlled at the vault level with three roles — vault_admin, editor, viewer — with team defaults and per-user overrides.

All of this is stored in PostgreSQL. Role changes take effect immediately. Every wiki operation — ingest, query, lint, role change — is recorded in an append-only audit log.

LLM Agnostic

Kosh doesn’t care which LLM you use. It ships with two adapters:

• Anthropic — Claude Opus/Sonnet via the native Messages API
• OpenAI-compatible — covers OpenAI, Gemini, DeepSeek, and Ollama (local models, no API key needed)

Switch providers by changing three lines in .env. The wiki operations — ingest, query, lint — work the same regardless of which model is running them. For teams that want to keep data on-premises, Ollama + a capable local model is a fully supported path.

The Developer Workflow

The part I’m most excited about is the MCP server.

Kosh ships a Model Context Protocol server. Add it to Claude Code, Cursor, or VS Code and the wiki becomes a native tool — no context switching, no copy-paste, no manual saving.

{
  "mcpServers": {
    "kosh": {
      "command": "/path/to/kosh-mcp",
      "env": {
        "KOSH_SERVER_URL": "http://your-server:8080",
        "KOSH_API_KEY": "kosh_...",
        "KOSH_DEFAULT_VAULT": "engineering"
      }
    }
  }
}

With this configured and a few lines in your project’s CLAUDE.md:

Before answering architecture questions, check the wiki with wiki_query.
When you explain a non-obvious design decision, save it with wiki_ingest.

Now Claude captures knowledge as a side effect of normal work. A developer asks why the auth middleware works a certain way. Claude queries the wiki, finds the answer, explains it — and if the answer wasn’t there, saves the explanation for next time. The wiki grows without anyone deciding to maintain it.

The MCP tools are:

• wiki_query — ask a question, get a cited answer
• wiki_ingest — integrate a document or text block into the wiki
• wiki_ingest_file — ingest a file by path
• wiki_list_pages — browse the wiki structure
• wiki_read_page — read a specific page
• wiki_lint — run a health check
• wiki_list_vaults — see available vaults

Lint: Keeping the Wiki Honest

Knowledge bases rot not just from neglect but from inconsistency. Two engineers use “service mesh” to mean different things. A concept page references an entity that was renamed six months ago. A decision from 2025 contradicts a decision from 2026 and nobody noticed.

koshctl lint --vault engineering runs the LLM over your entire wiki and surfaces:

• Orphans — pages with no incoming links
• Missing pages — links that point to pages that don’t exist
• Contradictions — claims that conflict with each other
• Stubs — pages with insufficient content
• Gaps — topics mentioned repeatedly but never given their own page

Run it monthly. Run it before a new hire’s first day. Run it as a pre-release ritual. The wiki stays coherent.

What’s Next

Kosh today covers the core loop: ingest, query, lint, access control. The roadmap has three areas I want to tackle next:

Integrations — a Slack bot (react 📚 to any message to capture it), GitHub webhooks (auto-ingest merged PRs and ADRs), and an Obsidian inbox watcher (drop files into raw/, they get ingested automatically).

Knowledge quality — pre-ingest disambiguation for term conflicts, per-team namespace prefixes so two teams’ definitions of “pipeline” don’t collide, and a living wiki schema with koshctl schema suggest to help the schema evolve based on what the wiki actually contains.

Vault management — a PATCH /v1/vaults/:vault endpoint so you can rotate an Obsidian API key without delete-and-re-register, and per-operation model routing (LLM_INGEST_MODEL, LLM_QUERY_MODEL) for teams that want a fast cheap model for queries and a capable model for ingestion.

Getting Started

git clone https://github.com/kunalkushwaha/kosh
cd kosh
cp .env.example .env
# edit .env: set VAULT_ENCRYPTION_KEY, LLM_API_KEY

docker compose up -d postgres
go build -o koshctl ./cmd/koshctl
./koshctl bootstrap --email you@yourcompany.com --name "Your Name"

Full walkthrough: docs/setup.md

Where the idea came from

Two things collided.

I’ve been taking the Data Strategy course at UC Berkeley Executive Education. One of its core arguments is that data compounds — organizations that treat knowledge as a managed, evolving asset pull ahead of those that treat it as a byproduct. The course frames this at the enterprise level: pipelines, governance, culture. But the same logic applies to a small team. Knowledge that is captured, connected, and kept current is a strategic asset. Knowledge scattered across Slack and stale docs is just noise.

Around the same time, Andrej Karpathy shared a gist describing the LLM Wiki pattern and a tweet about it. The idea: instead of RAG (re-deriving answers from raw documents on every query), use an LLM to maintain a persistent, structured wiki. The wiki is the compounding artifact. Every new source enriches it. Every query draws from everything already synthesized.

Kosh is just what happened when I decided to actually build that for a team.

Why Now

LLMs are good enough at structured generation that the ingest pipeline is actually reliable. A year ago, asking a model to read a document and emit well-formed JSON with frontmatter, wikilinks, and consistent tags would fail too often to be useful. Today, with the right prompt and a capable model, it works well enough to build a team workflow around.

The Obsidian Local REST API plugin made the storage layer clean. PostgreSQL made the access control simple. Go made the server fast to write and easy to deploy.

The pieces were all there. Kosh is just the assembly.

Kosh is MIT licensed. The code is at github.com/kunalkushwaha/kosh. Issues, PRs, and feedback welcome.

If you build something with it — or try to and hit a wall — I’d like to hear about it.

Streaming makes AI feel alive — tokens show up instantly, long tasks feel responsive, and multi‑step workflows become explainable as they run. In this post, we’ll build two streaming experiences with AgenticGoKit:

• A minimal “simple-streaming” chat
• A sequential multi‑agent “streaming_workflow” with step-by-step progress

We’ll also cover when to use streaming, why it helps, and a few gotchas and tips.

originally posted at : https://kunalkushwaha.github.io/2025/10/26/streaming-agenticgokit/

What is streaming and why it matters

Instead of waiting for the full response, streaming lets you consume output as it’s generated (token‑by‑token or chunk‑by‑chunk). That enables:

• Real‑time feedback: Users see progress immediately
• Better UX for long tasks: No “blank screen” pause
• Step visibility in workflows: Know which agent/step is running
• Early assessment: Skim partial output and course‑correct sooner

Under the hood, AgenticGoKit vNext exposes a Stream you can iterate over, with multiple chunk types like text deltas, metadata, tool calls, and final completion signals.

Prerequisites

• Go installed and working in this repo
• Ollama running locally (default http://localhost:11434)
• Model: gemma3:1b
• Repo paths in this post are relative to the project root

Pull the model if needed:

ollama pull gemma3:1b

Alternatively, you can use OpenAI or Azure OpenAI instead of Ollama by setting API keys and pointing your agent config to those providers:

# OpenAI
$env:OPENAI_API_KEY = "<your-openai-api-key>"

# Azure OpenAI
$env:AZURE_OPENAI_KEY = "<your-azure-openai-key>"
# Your Azure Base URL typically looks like:
# https://<your-resource-name>.openai.azure.com/

Part 1: Minimal simple-streaming

The example lives here: examples/vnext/simple-streaming/main.go.

It creates a small chat agent and prints tokens as they arrive:

// Start streaming
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

stream, err := agent.RunStream(ctx, prompt)
if err != nil {
    log.Fatalf("Failed to start streaming: %v", err)
}

// Print tokens as they arrive
for chunk := range stream.Chunks() {
    if chunk.Error != nil { fmt.Printf("\n❌ Error: %v\n", chunk.Error); break }
    switch chunk.Type {
    case vnext.ChunkTypeDelta:
        fmt.Print(chunk.Delta) // token-by-token
    case vnext.ChunkTypeDone:
        fmt.Println("\n\n✅ Streaming completed!")
    }
}

// Always check the final result
_, _ = stream.Wait()

Run it:

cd examples/vnext/simple-streaming
go run .

You’ll see something like:

Notes:

• The example uses Ollama with gemma3:1b. Adjust the model/provider in the config if needed.
• Always call stream.Wait() after consuming chunks to surface any trailing errors.

Part 2: Multi‑agent streaming workflow

Now, let’s level up with a sequential, two‑agent workflow that streams each step in real time. Code: examples/vnext/streaming_workflow/main.go.

We’ll create two specialized agents — Researcher and Summarizer — and wire them into a vNext Workflow. Each step streams its own tokens and emits metadata so you know what’s happening.

Defining agents

func CreateResearcherAgent() (vnext.Agent, error) {
    return vnext.QuickChatAgentWithConfig("Researcher", &vnext.Config{
        Name:         "researcher",
        SystemPrompt: "You are a Research Agent...",
        Timeout:      60 * time.Second,
        LLM: vnext.LLMConfig{ Provider: "ollama", Model: "gemma3:1b", Temperature: 0.2, MaxTokens: 300, BaseURL: "http://localhost:11434" },
    })
}

func CreateSummarizerAgent() (vnext.Agent, error) {
    return vnext.QuickChatAgentWithConfig("Summarizer", &vnext.Config{
        Name:         "summarizer",
        SystemPrompt: "You are a Summarizer Agent...",
        Timeout:      60 * time.Second,
        LLM: vnext.LLMConfig{ Provider: "ollama", Model: "gemma3:1b", Temperature: 0.3, MaxTokens: 150, BaseURL: "http://localhost:11434" },
    })
}

Using OpenAI or Azure OpenAI

Where the Ollama LLM config is defined above, you can swap in OpenAI or Azure OpenAI with minimal changes:

// OpenAI
LLM: vnext.LLMConfig{
    Provider: "openai",
    Model:    "gpt-4",
    APIKey:   os.Getenv("OPENAI_API_KEY"),
}

// Azure OpenAI
LLM: vnext.LLMConfig{
    Provider: "azure",
    Model:    "gpt-4",
    BaseURL:  "https://your-resource.openai.azure.com/",
    APIKey:   os.Getenv("AZURE_OPENAI_KEY"),
}

Notes:

• Keep the rest of the streaming code exactly the same; provider selection is handled via LLMConfig.
• Ensure the appropriate environment variables are set in your shell before running the examples.

Building a sequential workflow

workflow, err := vnext.NewSequentialWorkflow(&vnext.WorkflowConfig{ Mode: vnext.Sequential, Timeout: 180 * time.Second })
if err != nil { log.Fatal(err) }

_ = workflow.AddStep(vnext.WorkflowStep{
    Name:  "research",
    Agent: researcher,
    Transform: func(input string) string {
        return fmt.Sprintf("Research the topic: %s. Provide key information, benefits, and current applications.", input)
    },
})

_ = workflow.AddStep(vnext.WorkflowStep{
    Name:  "summarize",
    Agent: summarizer,
    Transform: func(input string) string {
        return fmt.Sprintf("Please summarize this research into key points:\n\n%s", input)
    },
})

Running with streaming

ctx := context.Background()
stream, err := workflow.RunStream(ctx, topic)
if err != nil { log.Fatal(err) }

for chunk := range stream.Chunks() {
    switch chunk.Type {
    case vnext.ChunkTypeMetadata:
        if stepName, ok := chunk.Metadata["step_name"].(string); ok {
            fmt.Printf("\n🔄 [STEP: %s] %s\n", strings.ToUpper(stepName), chunk.Content)
            fmt.Println("─────────────────────")
        }
    case vnext.ChunkTypeDelta:
        fmt.Print(chunk.Delta)
    case vnext.ChunkTypeDone:
        fmt.Println("\n✅ Workflow step completed!")
    }
}

result, err := stream.Wait() // final success/error

Run it:

cd examples/vnext/streaming_workflow
go run .

What you’ll see:

🚀 vnext.Workflow Streaming Showcase
====================================

🔍 Testing Ollama connection...
✅ Ollama connection successful

🌟 vnext.Workflow Sequential Streaming
=====================================
🎯 Topic: Benefits of streaming in AI applications

💬 Real-time Workflow Streaming:
─────────────────────────────────

🔄 [STEP: RESEARCH] Step 1/2: research
Streaming is a really cool way to access content...

🔄 [STEP: SUMMARIZE] Step 2/2: summarize
Based on the research findings, here are the key points:

🎉 vnext.WORKFLOW STREAMING COMPLETED!

When to use streaming vs. non‑streaming

Without streaming:

User: "Research AI streaming benefits"
System: [Working... 60–90s of silence]
System: [Full results appear all at once]

With streaming:

User: "Research AI streaming benefits"
System: 🔄 [STEP: RESEARCH] … tokens stream live …
System: 🔄 [STEP: SUMMARIZE] … tokens stream live …
System: ✅ Workflow completed

Streaming shines when:

• The task takes more than ~1–2 seconds
• You want visibility into multi‑step progress
• You’re building chat UIs or CLIs where responsiveness matters

Tips, options, and best practices

• Always use contexts with timeouts for cancellation:

ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

• After consuming chunks, call stream.Wait() to catch final errors and access the final result
• Need only text? Use text‑only streaming to reduce noise
• For UIs, include metadata to display current step/agent
• Tune buffer size and flush intervals for your UX/perf needs

See core/vnext/STREAMING_GUIDE.md for:

• Chunk types (Text, Delta, Thought, ToolCall, ToolResult, Metadata, Error, Done)
• Stream options: buffer size, thoughts/tool calls, metadata, flush interval
• Utilities: CollectStream, PrintStream, StreamToChannel, AsReader

Troubleshooting

• Stream hangs or never finishes: use a context with timeout and ensure you read all chunks
• Missing output: verify you’re handling ChunkTypeDelta (token deltas) and/or ChunkTypeText
• Slow UI updates: try a larger buffer or longer flush interval
• Provider issues: confirm Ollama is running and the model is pulled

Wrap‑up

You now have two paths:

• Start simple with examples/vnext/simple-streaming to understand token streaming
• Build richer, explainable systems with examples/vnext/streaming_workflow

Both rely on the same Stream primitives, so once you’re comfortable with one, the other feels natural.

Contribute to AgenticGoKit
AgenticGoKit is an open-source Go framework for building, orchestrating, and deploying intelligent agents LLM-agnostic, event-driven, and production-ready.

Join us to add LLM providers, improve docs, build new agent workflows, fix bugs, or enhance code quality.

Introduction

Building intelligent AI systems that can access and reason over vast amounts of information has traditionally been complex and time-consuming. What if you could create a production-ready RAG (Retrieval-Augmented Generation) system with multiple AI agents in just a few minutes?

In this tutorial, we’ll walk through building a complete RAG-powered multi-agent system using AgenticGoKit, a powerful Go framework that simplifies the creation of sophisticated AI applications.

Who This Guide Is For

• New Developers: Get started with AI agent development
• AI Enthusiasts: Learn about RAG and multi-agent systems
• Go Developers: Leverage Go’s power for AI applications
• Anyone: Interested in building knowledge-aware AI systems

What We’ll Build

By the end of this tutorial, you’ll have:

1. A multi-agent AI system with 3 collaborative agents

2. A vector database (PostgreSQL + pgvector) for knowledge storage

3. Document ingestion pipeline that automatically chunks and embeds content

4. RAG-powered responses that cite sources from your knowledge base

5. CLI tools for managing your knowledge base

Prerequisites

• Go 1.21+ installed
• Docker Desktop for the database
• OpenAI API key (or Ollama for local models)
• 5 minutes of your time!

Step 1: Install AgenticGoKit CLI

First, let’s install the AgenticGoKit command-line interface:

$ go install github.com/kunalkushwaha/agenticgokit/cmd/agentcli@latest

Verify the installation:

$ agentcli version

Step 2: Create Your RAG Project

AgenticGoKit comes with pre-built templates for common use cases. Let’s create a RAG system:

$ agentcli create knowledge-assistant -template rag-system
$ cd knowledge-assistant

This creates a complete project structure:

knowledge-assistant/
├── agentflow.toml          # Configuration file
├── main.go                 # Application entry point
├── agents/                 # Agent implementations
├── docker-compose.yml      # PostgreSQL + pgvector setup
├── setup.bat/setup.sh      # Database setup scripts
└── documents/              # Your knowledge base files

Step 3: Start the Vector Database

The template includes a pre-configured PostgreSQL database with pgvector extension:

# On Windows
$ ./setup.bat

# On Linux/Mac
$ ./setup.sh

This starts a PostgreSQL container with:

• pgvector extension for vector similarity search
• Pre-configured database named `agentflow`
• Automatic initialization with required tables

Step 4: Configure Your API Key

Set your OpenAI API key (or skip this step if using Ollama):

# Windows PowerShell
$env:OPENAI_API_KEY="your-api-key-here"
# Linux/Mac
export OPENAI_API_KEY="your-api-key-here"

Step 5: Add Knowledge to Your System

Now comes the exciting part! Let’s add some knowledge to our system. Create some sample documents:

mkdir documents
# Create `documents/ai-fundamentals.md`
# Create `documents/multi-agent-systems.md`

Step 6: Upload Documents to Knowledge Base

Use AgenticGoKit’s built-in knowledge management commands:

$ agentcli knowledge upload ./documents/ - recursive - tags "ai,tutorial,fundamentals"

You’ll see detailed output showing:

- Document processing and chunking

- Embedding generation using OpenAI

- Vector storage in PostgreSQL

- Automatic tagging and metadata extraction

Step 7: Test Knowledge Retrieval

Let’s verify our knowledge base is working:

# List all documents
agentcli knowledge list
# Search for specific topics
agentcli knowledge search "What is machine learning?"
# Show knowledge base statistics
agentcli knowledge stats

Step 8: Test Your RAG System

Now let’s test the complete RAG system:

$ go run . -m "What are the different types of machine learning?"

You should see output like:

=== Agent Responses ===
Agent agent1 (Step 1):
Based on the knowledge base, there are three main types of machine learning:
1. **Supervised Learning**: This involves training AI models with labeled data,
where the system learns from input-output examples.
2. **Unsupervised Learning**: This approach focuses on finding patterns in
unlabeled data without specific target outputs.
3. **Reinforcement Learning**: This method involves learning through trial and
error, where agents learn optimal actions through rewards and penalties.
These approaches form the foundation of modern AI systems and can be combined
for more sophisticated applications.
Sources: documents/ai-fundamentals.md
Completed at: 14:32:15
Summary: 1 agents completed successfully

Step 9: Experiment with Different Orchestration Modes

The beauty of AgenticGoKit is its flexibility. Let’s try different agent orchestration patterns by modifying `agentflow.toml`:

Sequential Mode (Default)

[orchestration]
mode = "sequential"
sequential_agents = ["agent1", "agent2", "agent3"]

Test it:

$ go run . -m "Explain multi-agent systems and their benefits"

Collaborative Mode

[orchestration]
mode = "collaborative"
collaborative_agents = ["agent1", "agent2", "agent3"]

Maintenance Commands

# Validate knowledge base health
$ agentcli knowledge validate
# Clear specific documents
$ agentcli knowledge clear -source "old-docs/"
# Interactive clearing with confirmation
$ agentcli knowledge clear -interactive

Understanding the Configuration

Let’s examine the key configuration in `agentflow.toml`:

# Memory and RAG Configuration
[agent_memory]
provider = "pgvector"
connection = "postgres://user:password@localhost:15432/agentflow?sslmode=disable"
enable_rag = true
chunk_size = 1000
chunk_overlap = 100
knowledge_score_threshold = 0.7
# Embedding Configuration
[agent_memory.embedding]
provider = "openai"
model = "text-embedding-3-small"
cache_embeddings = true
# Agent Configuration
[agents.agent1]
role = "agent1"
description = "Collaborative agent with RAG capabilities"
system_prompt = "You are a helpful AI assistant with access to a knowledge base. Always cite sources when using retrieved information."
capabilities = ["analysis", "text_analysis", "data_processing"]
enabled = true

Key Features Demonstrated

1. Document Chunking

• Automatic text splitting with configurable chunk size
• Overlap handling to maintain context
• Metadata preservation

2. Vector Embeddings

• OpenAI text-embedding-3-small integration
• Automatic embedding generation and caching
• Efficient similarity search

3. Multi-Agent Orchestration

• Sequential, collaborative, and parallel modes
• Agent specialization and coordination
• Configurable workflows

4. Knowledge Management

• CLI-based document upload and management
• Search with filtering and thresholds
• Statistics and health monitoring

5. RAG Integration

• Automatic context retrieval for agent queries
• Source attribution in responses
• Configurable relevance thresholds

Conclusion

In just 5 minutes, we’ve built a sophisticated RAG-powered multi-agent system that demonstrates the power of modern AI development. But this is just the beginning!

What We Accomplished

• Complete RAG System with vector database and knowledge management
• Multi-Agent Orchestration with configurable collaboration patterns
• Production-Ready Setup with monitoring and CLI tools
• Extensible Architecture ready for your custom requirements

The Real Magic

AgenticGoKit removes the complexity barrier that has traditionally made advanced AI systems accessible only to large teams with specialized expertise. Now, any developer can build sophisticated AI applications in minutes, not months.

Your Next Adventure Awaits

The AgenticGoKit GitHub repository is packed with examples, documentation, and a growing community of developers building the future of AI applications.

Don’t just read about it — dive in and start building!

🌟 Found this helpful? Give the AgenticGoKit repo a star and join the community of developers transforming how we build AI systems!

Start Your Next Project Today

# Pick a template and start building
$ agentcli template list
$ agentcli create my-next-ai-project --template <your-choice>
$ cd my-next-ai-project
$ go run . -m "Hello, intelligent world!"

When I started my CTO program at Berkeley in June 2025, I knew one thing for certain: over the next few months I’d be working on projects that required a lot of collaboration, iteration, and structure. One of the frameworks I wanted to use heavily was the Business Model Canvas (BMC) — a simple yet powerful way to visualize, test, and refine business ideas.

The problem?

I couldn’t find a free, collaborative tool that truly fit my needs.
Most tools I tried were either:

• Locked behind paywalls,
• Too clunky and unintuitive for quick brainstorming, or
• Lacking real-time collaboration features.

And since my team and I will be co-creating and refining our business models over the next 6–8 months, I needed something reliable, simple, and collaborative.

So, instead of compromising, I decided to build my own.

The Birth of Canvasly

Armed with vibe coding and Firebase Studio, I built Canvasly — a lightweight web application designed for one purpose:
👉 To make it effortless to create, edit, and collaborate on Business Model Canvases.

With Canvasly, you and your team can:

• Work together in real-time,
• Save your canvases in the cloud,
• Keep things structured yet flexible for brainstorming.

It’s simple, minimal, and focused. Exactly what I needed — and hopefully what other entrepreneurs, innovators, and students might find useful too.

You can try it here: https://canvasly.plankei.com/

Why I’m Sharing This

I didn’t set out to build a product for others. Honestly, Canvasly started as a personal necessity for my own project work at Berkeley. But along the way, I realized that this gap wasn’t just my problem — it’s a common frustration for anyone working on business models in a collaborative environment.

So, I decided to make it public.

If you’re a student, entrepreneur, or team looking for a free, no-friction tool to collaborate on business models, Canvasly might help you the same way it’s helping me and my team.

Looking Ahead

This is just the beginning. Over the coming months, I’ll be refining Canvasly as I continue using it for my CTO program projects. Feedback is welcome — if you try it out and have ideas or run into issues, I’d love to hear from you.

Sometimes, the best tools are born out of personal frustration. Canvasly is one of those stories.

Try it here: https://canvasly.plankei.com/