Skip to main content

AI assistant (archetype)

AI assistant (archetype)

Archetype pages on DecAIHub describe common project blueprints — recurring patterns of how crypto AI projects are built, what they offer, and what role AI plays in their product. The "AI assistant" archetype covers projects whose primary product is an AI assistant: a system that helps users answer questions, complete tasks, or make decisions by retrieving relevant information and presenting it in a useful way.

In short: in this archetype the assistant IS the product — a conversational AI layer that responds to user requests but does not act autonomously on the user's behalf.

What defines this archetype

A project fits the AI assistant archetype when its core offering is a system that responds to user prompts with context-aware answers, recommendations, or analysis. Unlike AI agents, assistants do not take independent action — they inform and advise, but the user retains control over execution. Unlike simple chatbots, assistants typically incorporate retrieval, ranking, or domain-specific knowledge rather than relying on generic text generation alone. On the assistant–copilot–chatbot–agent spectrum, assistants sit in the low-to-medium autonomy range: more capable than a chatbot, less autonomous than a copilot or agent.

From a product perspective, the archetype is defined by request–response interaction: the user initiates each meaningful exchange, and the system’s job is to assemble a helpful reply. The boundary that matters for classification is whether the assistant avoids autonomous execution without explicit user approval in a separate step — a distinction that separates assistant-centric projects from agent-centric ones.

Common patterns

Crypto knowledge assistants

Conversational AI for blockchain questions. These assistants answer user queries about tokens, protocols, wallets, and on-chain activity. They typically combine an LLM with retrieval from blockchain data sources, documentation, and market feeds. The value depends on whether the assistant provides accurate, up-to-date crypto-specific answers or merely forwards prompts to a generic model.

Weak implementations may look fluent while hallucinating addresses, parameters, or protocol behavior.

Typical AI components: AI chat assistant for crypto, AI assistant for blockchain queries, NLP-based crypto Q&A.

Trading and portfolio assistants

Decision support for trading and portfolio management. These assistants help users evaluate positions, review market conditions, and consider trade parameters — but the user executes the trade. The AI surfaces analysis; the human acts on it. This pattern is common in projects that bridge AI and DeFi without granting the AI autonomous execution rights.

The archetype describes product structure, not reliability of any specific implementation.

Typical use cases: AI-assisted trading, portfolio analysis assistant, AI-powered market insights.

Community and support assistants

Automated help for project communities. These assistants moderate channels, answer frequently asked questions, onboard new users, and summarize governance discussions. They operate inside messaging platforms (Telegram, Discord) and serve the project's community rather than external end users.

Typical AI components: AI community assistant, AI moderation bot, AI-powered FAQ assistant.

Developer assistants

AI tools for smart contract and dApp development. These assistants help developers write, review, or audit smart contracts, generate boilerplate code, or explain protocol documentation. The AI component is typically an LLM fine-tuned or prompted for Solidity, Rust, or Move, sometimes augmented with static analysis tools.

Typical AI components: AI code assistant, smart contract auditor assistant, AI developer copilot.

What to verify

When reading a project card with an assistant component, check:

  • Real NLP or keyword matching? A genuine assistant uses machine learning — an LLM, retrieval-augmented generation (RAG), or a fine-tuned model. A system that matches keywords and returns canned responses is automation, not AI.
  • Own model or API wrapper? Does the project train, fine-tune, or meaningfully customize a model, or does it forward prompts to a third-party API and return the result unchanged? An API wrapper alone does not constitute a proprietary AI assistant.
  • Domain-specific retrieval — does the assistant access and reason over crypto-specific data (on-chain state, protocol docs, market feeds), or does it rely solely on the base model's training data?
  • Tier-1 evidence — public demos, API documentation, model cards, or benchmark results that demonstrate the assistant's actual capability.

Where this archetype appears in DecAIHub cards

  • Category — typically AI/Agents or a domain-specific combination, depending on the assistant's focus area.
  • AI component — should name a concrete mechanism: AI chat assistant, NLP-based assistant, RAG-powered assistant. Vague labels like "AI-powered" without specifics are a warning sign.
  • Use case — common values: AI assistant for crypto, AI-assisted trading, AI community assistant, smart contract code review.
  • ai_score — reflects how much verifiable evidence exists for the assistant's AI capability. See DecAI Fit.

What this archetype does not prove

  • Having a chatbot or assistant interface does not prove that the system uses real AI or proprietary technology. Many assistants are thin wrappers around third-party LLMs with no meaningful customization.
  • Labeling a product an "AI assistant" does not prove intelligence — the assistant may produce generic, non-specialized responses indistinguishable from a bare API call.
  • An assistant that answers crypto questions does not prove that the project itself is decentralized or that its token is necessary for the assistant to function.
  • High user engagement with an assistant does not prove AI quality — users may interact frequently with a simple bot without realizing it lacks real NLP. Check the evidence table.

Do not confuse with

  • AI agents archetype — agents perceive, decide, and act autonomously. Assistants respond to user requests but do not take independent action.
  • Assistant vs copilot vs chatbot vs agent — the conceptual spectrum page. This archetype page describes the common product pattern for assistant-centric projects specifically.
  • AI infra layer archetype — infrastructure projects provide tools and services to AI developers. An assistant is an application-level product, not infrastructure.
  • API wrapper — forwarding prompts to a third-party model and returning the result is a pass-through, not an assistant with proprietary capability.

Frequently asked questions

How is an assistant different from an agent on DecAIHub?

An assistant waits for user prompts and responds with information or suggestions. An agent (in the archetypal sense used on this wiki) is associated with higher autonomy: planning, tool use, and acting within defined permissions. If the product never executes actions unless the user manually confirms each step outside the model, classify it as assistant-first.

Can a project be both an assistant and something else?

Yes. Archetypes describe the primary product shape. A project may ship an assistant as the main interface and still include smaller automation features. Use the card’s AI component and use case fields to see what DecAIHub recorded as the dominant pattern.

Why does DecAIHub care about RAG and fine-tuning for assistants?

Because fluency alone is not evidence of domain competence. Retrieval and customization are common ways crypto assistants justify their claims: they bind the model to documentation, chain data, or project-specific corpora. Without that, the assistant may be indistinguishable from a generic chat product.

External references

See also

No comments to display

Back to top