MeDo

AI Conversation Generator.

Under every good chat screen sits a quiet set of decisions: who may speak, what counts as an event, how a streaming reply appends, and what happens when a user rewrites a question. MeDo generates the whole organizing pattern from those decisions — a typed message model, ordering and grouping rules, streaming semantics, branching, and compaction for threads that outgrow their welcome.

Conversation
C

Who Spoke Is a Data Question Before It Is a Design Question

A chat screen is easy; the model underneath is where implementations go wrong. The moment an agent does anything richer than reply with prose, 'a list of messages' stops being enough: a tool call is not a speaker, a system event has no author, a streamed reply is one message that keeps growing, and an edited question silently orphans the answer already on screen. Deciding the taxonomy — user turn, agent message, system event, tool call, tool result — and the rules that order and group them makes every downstream behavior tractable: scroll anchoring during streaming, retry after a failed tool, branching when a user rewrites a turn, compaction when the history outgrows the context window. Get the model right and any rendering looks reasonable; skip it and every new feature — citations, forks, summaries — becomes a special case bolted onto a flat array.

템플릿 4개

생성할 수 있는 Conversation 템플릿

모든 템플릿은 스크린샷이 아니라 실제 프롬프트입니다. 어떤 AI 에디터에든 붙여넣거나 MeDo에서 실행해 React + Tailwind 코드를 그대로 받으세요.

Strict orderLinear Thread

One Append-Only Line of Turns

The default organization model: every entry appends to the end, nothing forks, the transcript reads top to bottom. Right when the dialogue itself is the product.

Build a conversation view with a single append-only thread. Render five entry types in insertion order — user turns compact and right-leaning, agent replies as full-width markdown, system events as centered grey captions such as 'Conversation shared at 2:14 PM', tool calls as one-line labeled chips, and tool results indented beneath their call. New tokens stream into the open reply as one growing message, never fragments, pinned to bottom only while the reader is already there. A stop button finalizes the open reply with an interrupted marker. No branching: a rewritten question appends a correction. Entries above the visible window lazy-render from the stored array.

MeDo에서 시도하기
Tool-heavyRun Log

Turns Grouped Into Agent Runs

For agents that act: each request opens a run — a collapsible block holding the calls, results, and narrative it produced, with per-run status.

Build an agent conversation organized as a run sequence. Each user turn opens a run block with a timestamp header and a status line — running, succeeded, failed. Inside a block, render the agent's prose, tool call cards with the tool name and one-line argument summary, and results indented under their calls with exit status and duration. A running card shows animated ellipsis and elapsed seconds; a failed one expands to the error with a Retry-run action that resends the turn. When the next user turn arrives, collapse the finished run to its header line, expandable on click, so a long session reads as an index of requests. The docked composer below indicates which run the next reply joins.

MeDo에서 시도하기
BranchableFork Tree

Edit-and-Resend Branching With Siblings

The exploration model: rewriting any turn forks the thread, siblings persist, and a switcher moves between versions without losing anything.

Build a conversation with true branching. Any user turn offers Edit; committing it creates a sibling branch — the original path stays intact below a fork marker, the revised turn heads the new one. A switcher above the composer reads 'Branch 2 of 3', arrows moving between siblings; only the active path renders, moving to a sibling swaps the tail beneath the fork. Add a New-branch action that forks without editing, for trying a different instruction from that point. Model entries as a tree: each stores a parentId, and the visible thread is the path from root to the selected leaf. Only the open leaf accepts streamed tokens, and sibling counts persist across reload.

MeDo에서 시도하기
Long horizonCompacted Thread

Summary Stubs for Weeks-Long Conversations

The longevity model: settled turns compress into expandable summary stubs, the thread stays scannable at any age, and the verbatim boundary is always visible.

Build a conversation designed to stay readable across weeks. Keep the six most recent turns fully rendered; compact everything older into one summary stub pinned above them — 'Earlier: 14 turns about the Q3 pricing migration' — with Expand lazy-loading the original turns in place and Collapse re-summarizing. Compact system events like model switches and handoffs first. Build stubs from stored summaries, never on-the-fly regeneration, so they cannot drift from what happened. When a compaction boundary would split a tool call from its result, move the boundary to keep the pair together. Draw a subtle divider where the verbatim transcript begins, and append new turns with standard streaming — one growing message, bottom-pinned unless the reader scrolled up.

MeDo에서 시도하기

Conversation 커스터마이즈 방법

Name every speaker and event your product can produce

Write the taxonomy before the screen: user, agent, system event, tool call, tool result — plus whatever your domain adds, like a handoff-to-human entry. Anything not modeled will render as the wrong default later, usually as prose where a status belonged. When a new entry type appears mid-project, extend the model first and the renderer second; the reverse order is how flat message arrays acquire their fifteenth boolean flag.

Decide what streaming means for the scroll

Streaming appends into one open message — the entry is created once and grows — and the view pins to the bottom only while the reader is already there. If the user scrolled up to re-read, new tokens must not yank the viewport down. Ask for that anchor rule explicitly, plus a stop control that finalizes the open message with an interrupted marker instead of discarding what arrived.

Make branching a decision, not an accident

Edit-and-resend either forks — the original path survives and the edit starts a sibling — or it truncates everything after the edited turn. Both are legitimate; silently picking one is not, because truncation destroys work users thought was saved. If your product is about exploring options, model the thread as a tree with a parent pointer per entry and a visible switcher; if it is about answers, append corrections and skip branching entirely.

Compact old history on a budget and show the seams

Threads that live for weeks need compaction: recent turns stay verbatim, older ranges collapse into a summary stub the reader can expand. Build the stub from stored summaries rather than on-the-fly regeneration so it cannot drift from what actually happened, keep tool call-result pairs on the same side of a compaction boundary, and draw a divider where the verbatim transcript begins — readers should always know which parts are quote-accurate.

Conversation 컴포넌트를 사용하는 사람

Consumer AI chat product

The conversation is the product: a thread list in a sidebar, streaming replies anchored to the bottom, model-switch captions, and threads that persist across sessions.

Knowledge-base answer engine

Every agent reply carries citations to source documents, and the model distinguishes a retrieval tool call from the prose answer it produced — the difference between an auditable answer and a confident guess.

Writing and tutoring copilot

Multi-turn coaching where students rewrite their own prompts to explore alternatives — branching with sibling switchers is the core interaction, not an advanced feature.

Operations run console

Tool-heavy sessions rendered as runs: each request opens a block of calls, results, and narrative that collapses to a status line once the next request arrives.

웹사이트 유형별 Conversation 패턴

같은 conversation 컴포넌트를 게시되는 사이트 유형에 맞춰 조정합니다.

01 / 04

AI-First Products

When the conversation is the product, the pattern carries the full model: thread list, model-switch captions, streaming appends, and session persistence. The taxonomy tends to stay small and the prose quality carries everything.

Conversation 스타일과 변형

페이지의 나머지 부분과 어울리는 변형을 골라 바로 생성하세요.

01 / 04

Alternating Turns

Speaker identity encoded as alignment and fill — user turns right and tinted, agent turns left and plain. The most familiar reading contract, and the cheapest to parse at a glance.

React, Next.js, Vue, Svelte에서의 Conversation

React, Next.js, Vue 3, SvelteKit, Astro 또는 순수 HTML — 같은 conversation을 여섯 가지 방식으로 넣을 수 있습니다.

01 / 03

React Conversation

The pattern's core loop as a rendering switch: one row component that branches on the entry type, so the taxonomy lives in one place and a new type is one new case.

src/components/Conversation.tsx

function Row({ msg }: { msg: Msg }) {
  switch (msg.type) {
    case 'user':
      return <UserTurn text={msg.content} />
    case 'agent':
      return <AgentReply text={msg.content} streaming={msg.open} />
    case 'system':
      return <p className='text-center text-xs text-zinc-500'>{msg.content}</p>
    case 'tool_call':
      return <ToolCard name={msg.name} args={msg.args} running={msg.pending} />
    case 'tool_result':
      return <ToolOutput callId={msg.callId} status={msg.status} />
  }
}

// Ordering lives in the model: visiblePath is the root-to-leaf traversal.
<ol role='log' className='space-y-3'>
  {visiblePath.map((msg) => <Row key={msg.id} msg={msg} />)}
</ol>

Conversation을 프로젝트에 추가하는 방법

conversation 템플릿을 고르고 프로덕션에 배포하기까지 네 단계.

01~15min

Inventory Your Entry Types

List everything that can appear in a thread: user turns, agent prose, tool calls, results, system events, plus whatever your product adds like a human handoff. Anything not named now will render as the wrong default later.

02~10min

Set the Ordering Rules

Decide how entries sort, what groups together, and whether a tool result may ever sit apart from its call. Write the rules down; they become the backbone of the prompt you will generate from.

03~3min

Generate From the Taxonomy

Hand MeDo the typed message model — entry types, ordering, append behavior, fork rules — rather than a screenshot of a chat app. A view generated from its model absorbs new features; one generated from pixels grows special cases.

04~5min

Replay a Messy Session

Feed the generated view a real, ugly transcript: an interrupted stream, a failed tool, a question rewritten mid-thread, a week of history. The organization model is correct when the worst session still reads top to bottom.

Conversation에 대한 자주 묻는 질문

How is a conversation different from a chat panel?

The conversation is the organizing pattern; the chat panel is a widget that hosts it. The pattern defines the message taxonomy, ordering, streaming append semantics, branching, and history rules — the things that stay true whether the dialogue renders full-screen, in a rail, or in a drawer. The panel adds the embedding concerns: width, host-page context, focus, collapse behavior. When you generate a conversation with MeDo you are specifying the model; the same model can later be dropped into a panel, a full page, or a workspace column without redesign.

Isn't a conversation just a feed of messages?

They are near-opposites wearing similar markup. A feed is reverse-chronological content consumption: newest first, entries authored by others, no obligation to reply, read order is top to bottom starting from now. A conversation is turn-taking: strictly oldest-to-newest, the reader is a participant, the view anchors to the bottom while new content arrives, and a composer is the contract that the other side will answer. Reverse the order of a conversation and it stops working; a feed that anchored to its oldest post would be unreadable. Same rows, inverted time, different product.

What message types does a conversation model need?

Start with five: user turn, agent message, system event (model switches, shares, handoffs — things that happened with no participant speaking), tool call (a named action with arguments), and tool result (bound to its call, carrying status and duration). The binding rule matters as much as the list: a result must stay attached to its call even across compaction and virtualization. Add product-specific types deliberately — a human-agent takeover, a payment confirmation — rather than overloading prose, because each type earns its own rendering and its own rules.

How does streaming work without breaking the layout?

Create the reply entry once, then append tokens into that same entry — the list length never changes during a stream, so layout cannot jump. Anchor the viewport to the bottom only while the reader is already there, with a small threshold rather than exact equality. Resist rendering each chunk as its own element or re-rendering the whole list per token: long threads need windowed rendering with stable entry heights, and a stream that mutates one entry plays nicely with that. A stop control finalizes the open entry with an interrupted marker instead of deleting the partial text.

When should a conversation support branching?

When revising a question is part of the product — writing tools, tutoring, research exploration — branching turns 'I asked the wrong thing' into a feature: the edit forks a sibling, both survive, and a switcher moves between them. When the product is about dependable answers — support, ops — branching adds state you must explain for little gain; append a correction instead. The middle ground many products ship is edit-and-resend with visible fork count, so the cost of rewriting a turn is honest and the original answer is never silently discarded.

What is history compaction and when do I need it?

Compaction summarizes settled parts of a thread into a stub — 'Earlier: 14 turns about the pricing migration' — while keeping recent turns verbatim and expandable. You need it when either limit bites: the model's context window makes old turns expensive or impossible to send, or human readers face a scroll they will never finish. Compact by range, keep tool call-result pairs together across the boundary, build stubs from stored summaries so they cannot drift, and mark where the verbatim transcript begins. A thread a user can re-enter after three weeks is a retained user.