Skip to content

Product guide

How to use Asael.

A guide to Assistant, memory, workflows, connections, governed tools, evaluations, system health, and release evidence.

Private workspace links require an approved account. The demo uses sample content.

Working flow

Follow the goal through its controls.

Identity, source context, policy, evidence, and your review remain part of the work.

  1. 01

    Goal

    An operator submits a goal in Assistant; Demo uses sample content.

  2. 02

    Identity

    Session, tenant, actor, and role are resolved.

  3. 03

    Context

    Memory, RAG chunks, graph hints, and run history are assembled.

  4. 04

    Plan

    The goal becomes workflow nodes with risk and verification.

  5. 05

    Tools

    MCP, OpenAPI, and internal tools are classified before side effects.

  6. 06

    Approval

    Risky work pauses for human or policy approval.

  7. 07

    Observe

    Runtime events, SLOs, incidents, alerts, and diagnostics are recorded.

  8. 08

    Release

    Evaluation reports and release gates provide evidence for release review.

  9. 09

    Learn

    Useful results can become durable memory and future context.

Assistant

Choose how to approach the request.

Keep the goal, mode, source context, tools, approvals, history, and evidence together.

Open Assistant
  • Orchestrate

    Turn a goal into a governed plan, workflow, tool calls, evidence, and memory updates.

  • Research

    Use RAG, memory, source chunks, and graph context to answer questions with provenance.

  • Execute

    Run approved tools, dry runs, connector operations, and workflow ticks with audit records.

  • Learn

    Capture successful outcomes as durable memory, reusable plans, and operational knowledge.

Feature guide

Find the view for your work.

Each link opens the corresponding private workspace view. Access depends on your account and permissions.

Use cases

Examples of governed work.

These are example approaches. Available actions depend on connected sources, configuration, permissions, and required approvals.

  • Research and knowledge work

    Ask complex questions over source-backed memory and preserve useful answers.

    1. Ingest documents
    2. Retrieve with RAG
    3. Summarize with provenance
    4. Save durable memory
  • Operations automation

    Turn repeatable operational tasks into auditable workflows with approvals.

    1. Submit goal
    2. Plan workflow
    3. Run safe tools
    4. Recover or approve
  • Customer support agents

    Retrieve policy, inspect history, draft responses, and escalate risky actions.

    1. Load ticket
    2. Retrieve policy
    3. Draft answer
    4. Request approval
  • Security and compliance

    Track tenant isolation, auth failures, policy blocks, and signed release evidence.

    1. Inspect context
    2. Run eval
    3. Review audit
    4. Gate release
  • Connector-driven work

    Register external APIs without exposing platform secrets or private networks.

    1. Import spec
    2. Classify risk
    3. Dry run operation
    4. Execute with audit
  • Release readiness

    Use smoke tests, SLO snapshots, evaluation reports, and signing gates before deploys.

    1. Run smoke
    2. Check SLO
    3. Verify report
    4. Approve release

API map

Operating references.

These are route references, not executable examples. Protected operations require their existing authorization and review controls.

Auth and identity · 4 routes
  • /api/auth/login
  • /api/auth/logout
  • /api/auth/session
  • /api/auth/control-plane
Agent, memory, RAG, and knowledge · 8 routes
  • /api/agent
  • /api/memory
  • /api/memory/graph
  • /api/knowledge
  • /api/ingest
  • /api/retrieval/plan
  • /api/runs
  • /api/capabilities
Workflows, triggers, approvals, and operations · 12 routes
  • /api/workflows
  • /api/workflows/[id]
  • /api/workflows/[id]/tick
  • /api/workflows/[id]/signal
  • /api/workflows/executions
  • /api/workflows/plan
  • /api/workflows/tick
  • /api/triggers
  • /api/triggers/[id]/dispatch
  • /api/approvals
  • /api/approvals/[id]
  • /api/operations
Connectors and governed tools · 9 routes
  • /api/connectors
  • /api/connectors/[id]
  • /api/connectors/[id]/discover
  • /api/openapi-connectors
  • /api/openapi-connectors/[id]
  • /api/openapi-connectors/[id]/import
  • /api/connection-catalog
  • /api/tools
  • /api/tools/execute
Evaluation, release, observability, and incidents · 14 routes
  • /api/evaluations
  • /api/evaluations/[id]
  • /api/evaluations/[id]/report
  • /api/evaluations/[id]/report/verify
  • /api/release/evidence
  • /api/observability
  • /api/observability/slo
  • /api/observability/slo/policies
  • /api/incidents
  • /api/incidents/[id]
  • /api/incidents/[id]/actions
  • /api/alerts
  • /api/diagnostics
  • /api/health
Security and tenant isolation · 3 routes
  • /api/security/context
  • /api/security/audits
  • /api/security/isolation-report

Operations checklist

Review readiness before consequential work.

The application can connect to real systems. Review the relevant evidence and controls before running work.

  1. Set production secrets in Vercel: OpenAI, database, auth bootstrap, cron, internal smoke, and signing values.
  2. Confirm /api/health returns healthy before inviting operators.
  3. Run Production Smoke after every deployment and inspect release evidence.
  4. Use demo mode for prospects and dashboard readiness for new workspaces before connecting real systems.
  5. Register one connector at a time, start with dry runs, and require approval for high-risk operations.
  6. Review SLO warnings after smoke tests; cold-start latency warnings can be advisory when availability and errors are clean.
  7. Use approved private accounts. This deployment does not offer public registration or commercial checkout.
  8. Check observability, incidents, alert deliveries, and workflow queues after smoke runs or high-risk demos.

Keep the guide beside your work.

Use it while you connect a source, inspect a workflow, or review evidence.