JSX.Element> = {
line_chart: LineChartView,
bar_chart: BarChartView,
pie_chart: PieChartView,
document: ReadOnlyDocumentView,
};
export function ArtifactView({ artifact }) {
const Renderer = REGISTRY[artifact.artifact_type];
if (Renderer) return ;
// No renderer registered → fall back to an inline view (rendered directly
// in ArtifactView): an amber "Unknown artifact type" banner plus a
// dump of JSON.stringify(artifact.payload). There is no separate component.
return /* inline unknown-artifact fallback */;
}
```
Charts (line / bar / pie) are rendered by recharts components in [`chart-views.tsx`](https://github.com/petrosrapto/HAICO/blob/main/frontend/src/components/app/artifacts/chart-views.tsx). Multi-series data is auto-detected; each series gets a colour from a fixed palette matching the brand tokens.
### 10.3 Adding a new artifact type: the recipe
Goal: a new artifact type the agent can produce, e.g. a sortable `
` that renders structured data the LLM doesn't need to read.
**1. Pick a discriminator string:** e.g. `"data_table"`.
**2. Add a tool that returns a `(content, artifact)` tuple** in `backend/app/tools/tables.py`:
```python theme={null}
@workspace_tool(name="data_table", ...)
async def data_table(self, repo, columns, rows, title):
payload = {"columns": columns, "rows": rows, "title": title}
return (f"Generated a {len(rows)}-row table.",
{"artifact_type": "data_table", "title": title, "payload": payload})
```
**3. Register the collection** in `tools/manager.py`: `return [..., TableTools(thread_id)]`.
**4. Mention the new tool** in `HAICO_SYSTEM_PROMPT`'s "Tool guide" section so the agent knows when to use it.
**5. Add a frontend renderer** in `frontend/src/components/app/artifacts/table-view.tsx`:
```tsx theme={null}
export function DataTableView({ artifact }) {
const { columns, rows } = artifact.payload as ...;
return ;
}
```
**6. Add ONE entry to the registry:** `REGISTRY.data_table = DataTableView;`
**7. (Optional) Add an icon mapping** in `artifact-panel.tsx` so the dropdown shows the right glyph for the new type.
Nothing else changes. The decorator persists the artifact, the SSE event fires automatically, the `ArtifactPanel` auto-selects it, and the registry dispatches to your renderer.
### 10.4 Why typed payloads, not React code or SVG
We deliberately do *not* let the agent emit React code or SVG markup. The trade-offs:
| Option | Pros | Cons |
| ------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| **Typed JSON payload** (chosen) | Safe; declarative; agent only learns the schema; renderer is in the codebase, reviewable | Must add a renderer per new type |
| Vega-Lite JSON spec | Single very general schema, off-the-shelf renderer | Heavy bundle; agent must learn a complex schema |
| React code | Maximally flexible | XSS / sandbox nightmare; needs eval; review surface explodes |
| Server-rendered SVG / PNG | Frontend trivially displays | Not editable; agent has to run a render lib server-side |
This follows the typed-artifact pattern (`{artifact_type, payload}`): LLM produces typed data, frontend owns rendering.
### 10.5 Past-artifact access for the agent
The agent can re-fetch any past artifact via two tools in [`artifacts.py`](https://github.com/petrosrapto/HAICO/blob/main/backend/app/tools/artifacts.py):
* `list_artifacts(artifact_type?, limit?)` returns a compact index: `#42 [turn 3] line_chart: Q1 vs Q2`.
* `get_artifact(artifact_id)` returns the artifact as a JSON string of `{id, type, title, turn_index, payload}` (the payload plus its metadata, not the bare payload).
Use cases: "compare to the chart from turn 3", "what did the bar chart say?", "summarise across all the tables we've built".
The system prompt instructs the agent to **refer to artifacts by id and describe what changed** rather than re-emitting payloads verbatim; this is the whole point of the artifact channel (large data that bypasses the LLM context).
***
## 11. Where to read next
* [architecture.md](/docs/architecture): the system's static structure, data stores, tool-composition model, and the decisions behind it (→ ADRs)
* [conversation-branching.md](/docs/conversation-branching): the turn-as-commit model, branching, restore, and the trajectory graph
* [tools.md](/docs/tools): the `@workspace_tool` conventions cheat-sheet
* [database-schema.md](/docs/database-schema): the full persistent data model after migration 0007
* [adr/](/docs/adr/index): the Architecture Decision Records, the *why* behind the structure (esp. [ADR-0003](/docs/adr/0003-conversation-branching-via-new-thread-and-state-seeding), [ADR-0004](/docs/adr/0004-hierarchical-plan-and-objective))
* `Human-AI Co-Construction Paper/`: the formal HAI-Co² model