AdvisorClaw Technical DDQ

3.1 Deployment Model

AdvisorClaw is currently deployed as a dedicated, single-instance environment on a fresh Ubuntu 24.04 virtual private server.

The implemented deployment path provisions:

This architecture is intentionally designed to avoid the risks and limitations of shared multi-tenant AI application patterns.

3.2 Why This Architecture Was Chosen

AdvisorClaw uses dedicated virtual private servers because this architecture provides meaningful operational and security advantages for advisor-facing AI deployments.

3.3 Current Provisioning Flow

The current provisioning flow is request-driven and managed. It includes:

1. 01
   intake or deployment request
2. 02
   request persistence in Supabase
3. 03
   deployment job creation
4. 04
   VPS provisioning
5. 05
   secure deployment bundle upload and execution
6. 06
   runtime and workspace configuration
7. 07
   validation checks before handoff

4.1 High-Level Topology

The current deployed topology is:

The gateway layer runs behind the public edge and is isolated from direct public exposure. Internal services communicate over loopback within the server.

4.2 Architectural Principles

4.3 Runtime Components

4.4 Why This Is More Controlled Than Typical SaaS AI Patterns

Many AI tools used in enterprises today are essentially shared hosted applications sitting on centralized servers, with user prompts and outputs flowing through common application layers. AdvisorClaw differs in a few important ways:

For firms that care about operational control, data boundaries, and workflow-specific AI behavior, this is a materially more controlled architecture than lightweight shared-server AI tooling.

5.1 Multi-Agent Structure

AdvisorClaw supports a primary assistant plus specialist roles. The current deployment bundle explicitly configures:

This enables a more structured execution model than a single general-purpose chatbot.

5.2 Execution Model

AdvisorClaw is built to support:

This makes it well suited for research, document-heavy workflows, recurring operational tasks, and advisory support use cases where context continuity matters.

5.3 Why This Matters

A core limitation of many AI tools is that they are session-bound and prompt-bound. AdvisorClaw is designed around persistent operating context, which allows the system to retain continuity, produce durable work artifacts, and work more like a deployed digital operating environment than a transient chat session.

6.1 Persistent Workspace Design

Each AdvisorClaw deployment includes a persistent workspace rather than a temporary chat surface. The workspace supports:

6.2 Memory Architecture

In practical customer terms, AdvisorClaw memory is a persistent file-backed structure informed by QMD-oriented patterns. This memory system is intended to support:

This architecture is evolving and is expected to become more sophisticated over time. Future deployments are expected to incorporate richer graph-RAG-style memory architectures for deeper context management and retrieval.

6.3 Customer File Access

Customers can upload and download files into and out of the workspace and session environment. That is an intentional design decision. AdvisorClaw is meant to integrate into real firm workflows, not function as a sealed black box.

The workspace can serve as a live operating layer that interacts with documents, files, and other workflow artifacts.

6.4 Why the File-Based Model Is Strong

The file-based model is a major differentiator because it gives the deployment:

This is fundamentally different from AI tools that only expose ephemeral prompts and outputs.

7.1 Open Architecture by Design

AdvisorClaw is designed to be model-provider-flexible. It can interface with a range of LLM APIs and can be configured based on customer preferences, privacy posture, workflow requirements, and vendor policy. This is not a closed-model application. It is a customizable AI operating framework.

7.2 Current Supported Provider Paths

Current deployment paths support direct integration with:

These providers can be configured at deployment time depending on customer requirements and environment settings. The architecture is intentionally designed so that model-provider selection is not rigidly tied to a single vendor or fixed model SKU.

7.3 How Model Privacy Works in Practice

AdvisorClaw is designed so that model-provider privacy characteristics inherit from the underlying API vendors being used in a given deployment. In practical terms:

This gives customers more flexibility to align model usage with their own preferences and vendor requirements.

7.4 Model Governance Advantage

Because AdvisorClaw runs in a dedicated environment, customers have a stronger architectural foundation for controlling:

That is a meaningful advantage over generic AI SaaS products that route all customer activity through a shared application layer.

8.1 Planned Self-Hosted Model Path

IDX is developing IDX Intellex, a self-hosted LLM offering intended to become an optional model path for AdvisorClaw deployments. IDX Intellex is based on current open-source frontier model families and is being customized and fine-tuned for financial use cases.

8.2 Intended Value of IDX Intellex for AdvisorClaw Customers

The expected benefits of introducing Telex into the AdvisorClaw stack include:

8.3 Current Status

IDX Intellex should be represented as an upcoming capability rather than a current default deployment baseline.

AdvisorClaw currently supports API-based model-provider integrations, with IDX’s self-hosted IDX Intellex model path expected to become available as an optional deployment enhancement in the coming months.

9.1 Security-First Design Principles

AdvisorClaw is built around a security-aware deployment model from the start. The core security advantage is architectural:

This creates a more controlled operational security posture than many shared-server AI offerings.

9.2 Implemented Technical Controls

9.3 Secure Deployment Hygiene

Deployment and image-preparation materials show explicit attention to:

These are meaningful operational controls, especially in an environment where AI tools often grow out of generic cloud app patterns with weaker deployment boundaries.

9.4 Why This Is Strong for the Advisor Market

Advisory firms are often asked to evaluate AI vendors that run shared cloud applications with centralized prompt handling, shared application infrastructure, and broad vendor-side control of runtime behavior. AdvisorClaw offers a different model:

That makes it a strong fit for firms that want AI capability without defaulting to shared SaaS AI architecture.

10.1 Data Separation Model

AdvisorClaw has two clear data layers:

This separation helps keep runtime activity associated with the dedicated deployment rather than collapsing everything into a single centralized application data layer.

10.2 Workspace and Session Data

AdvisorClaw is intentionally designed around persistent local runtime state. That includes workspace artifacts, session data, and memory structures that live in the deployed environment.

This supports continuity, inspectability, workflow integration, and local control over working context.

10.3 Model Calls and Data Flow

AdvisorClaw is designed to call approved model vendors through API access. The privacy characteristics of those interactions depend on the specific providers configured for the deployment.

Because AdvisorClaw is open and configurable, customers can shape model-provider usage around their own requirements and preferences.

10.4 File Portability

Customers can move files into and out of the workspace. This allows the deployment to integrate with existing enterprise workflows and document systems rather than trapping work inside a closed product layer.

11.1 Current Integration Philosophy

AdvisorClaw is designed for integration rather than lock-in. The platform can work with model-provider APIs, file-based workflows, deployment and control-plane systems, customer-specific skills and tool layers, and enterprise processes that rely on documents, local runtime context, and durable work products.

11.2 Current Evidenced External Systems

11.3 Customer Customization

AdvisorClaw is intended to be highly customizable. That includes the ability to shape:

That openness is a core part of the product design.

12.1 AdvisorClaw’s Role

AdvisorClaw is designed for advisor workflows and includes compliance-oriented specialist capability, but its strongest current technical claim is that it provides a more controlled, private, and configurable AI operating environment for advisory use cases.

12.2 What Makes It Attractive for Regulated Environments

AdvisorClaw’s architecture is especially relevant for regulated or sensitive operating environments because it offers:

12.3 Accurate Positioning

The right public positioning is:

This DDQ does not need to overstate certifications to make that case. The architecture itself is already a compelling differentiator.

13.1 Current Access Model

Current deployments use authenticated access to the deployed AdvisorClaw environment and token-protected internal gateway configuration. The current private deployment access model is intentionally simple and controlled, aligned with a managed deployment approach.

13.2 Why This Matters

Because each deployment is customer-dedicated, access control can be applied at the deployment level rather than through a broad shared SaaS identity surface. This gives the platform a simpler and cleaner security boundary than products that multiplex large numbers of customers through the same runtime application layer.

14.1 Real Deployment Pipeline

AdvisorClaw is not just a concept or front-end shell. The reviewed implementation includes:

14.2 Operational Validation

The deployment flow includes real validation around:

That matters because it means the deployment is built and checked as an operational system, not merely a marketing concept.

14.3 Robustness Story

AdvisorClaw’s robustness comes from a combination of:

These are strong technical foundations for security-aware AI deployment in advisory settings.

15.1 Current Rollout Style

AdvisorClaw is currently delivered through a managed private deployment model. That means:

15.2 Why That Is an Advantage at This Stage

For early customers, this approach allows tighter deployment quality, stronger environment shaping, more precise skills and workflow setup, closer alignment with real advisor use cases, and better security hygiene than a rushed self-serve rollout.

A. Deployment topology schematic

B. Founder provisioning flow schematic