Product Overview
II-Agent is built around one idea: a user should be able to move from intent to concrete output without juggling separate tools for planning, execution, content creation, and deployment.
Three Product Pillars
1. Full-Stack Development
The agent can scaffold, edit, and publish software projects. This shows up in the agents/,
projects/, files/, and connector-related domains.
2. Slides and Storybooks
The platform includes first-class content domains for visual outputs: slides, slide design, templates, storybooks, and media generation.
3. Deep Research
Research-specialized configuration, browsing capabilities, and session workflows support investigative tasks that can later feed into content or software outputs.
Interaction Modes
| Mode | Transport | Strength | Best used for |
|---|---|---|---|
| Agent | Socket.IO | Multi-step execution with tools, sandboxes, and streamed events | Building, editing, deploying, automation |
| Chat | REST + SSE | Direct model interaction with simpler orchestration | Q&A, model comparison, lightweight requests |
Primary Personas
Power user
- Works in agent mode daily.
- Iterates on projects and files.
- Connects custom APIs, models, and skills.
Casual user
- Uses chat mode for faster answers.
- Generates slides, storybooks, and media assets.
- Shares outputs without operating the full engineering surface directly.
Developer or integrator
- Reads the API and architecture surfaces.
- Extends domains, tools, connectors, or deployment paths.
- Uses the repo as a platform, not just an app.
Key Journeys
Agent journey
Login → create session → agent executes → review events/results → iterate → deploy or export
Chat journey
Login → pick model → send message → stream answer → continue thread → switch models
Content journey
Describe desired output → generate draft → refine structure/design → export or store assets
Credits and Billing
- Credits gate expensive LLM and tool usage.
- Bonus credits are consumed before regular credits.
- Billing and usage are tracked in dedicated domains instead of being hidden inside runtime code.
- User-visible balances and ledgers are part of the product contract, not an afterthought.
Why This Matters For The Docs
The docs need to cover:
- what the product is
- which mode to use
- which domain owns a capability
- how to run the system locally
- how to extend it without guessing
That is why this Docusaurus site is now organized around product surfaces and code ownership instead of a short install-only path.