Bardo Tools – Tool Profiles [SPEC]

Version: 4.0.0 Last Updated: 2026-03-14

Crate: bardo-tools | Prerequisites: 01-architecture.md

Profile-based tool loading for the bardo-tools Pi extension.

Reader orientation: This document specifies the profile-based tool loading system for the bardo-tools crate, part of Bardo’s DeFi tool library. Profiles control which tool adapters a Golem (a mortal autonomous agent compiled as a single Rust binary running on a micro VM) loads at boot, determining what actions it can take. Understanding the two-layer tool model from 01-architecture.md is a prerequisite. See prd2/shared/glossary.md for full term definitions.

Profile system

Set BARDO_PROFILE in the environment to control which tool adapters the bardo-tools extension loads at boot. Profiles determine which actionType values are valid for preview_action/commit_action. Profiles are composable – BARDO_PROFILE=trader,vault activates both.

17 tool categories

Total: ~210 tools across 17 categories. 12 categories have existing implementations; 5 (lending, staking, restaking, derivatives, yield) are specified but not yet implemented.

Profile composition

Multiple profiles can be combined:

# Activate both trader and vault profiles
BARDO_PROFILE=trader,vault

# Activate data + intelligence
BARDO_PROFILE=data,intelligence

The data category is implicitly included in all profiles. The full profile includes everything except testnet and bootstrap. The development profile extends full with testnet and bootstrap tools.

Observatory profile detail

The observatory profile is the Sleepwalker phenotype’s tool configuration. It loads only read tools (~72 total). No wallet is needed – the Sleepwalker never signs transactions. It observes the market, dreams about what it sees, and publishes structural understanding to the Lethe (formerly Commons). Because it never trades, it has no alpha to leak and can publish freely.

Conservative profile detail

The conservative profile loads all read tools plus a restricted set of ~40 write tools. Excluded: leverage operations, complex LP (concentrated liquidity below 50-tick ranges), flashloan tools, cross-chain bridge tools. Write operations are rate-limited to 10 per hour (vs 20 for standard profiles). Intended for risk-averse owners who want their Golem to trade but within tight bounds.

Profile filtering

Profile filtering uses the ToolDef.category field. Filtering happens once at extension initialization, not per-request:

#![allow(unused)]
fn main() {
let allowed = resolve_profile_categories(profile);
let tools: Vec<&ToolDef> = ALL_TOOL_DEFS
    .iter()
    .filter(|t| allowed.contains(&t.category))
    .collect();
}

Fine-grained overrides

The config file supports per-tool enable/disable that takes precedence over profiles:

[tools]
profile = "trader"
enable = ["intel_compute_vpin", "intel_compute_lvr"]
disable = ["uniswap_submit_uniswapx_order"]

Profile registry

The ProfileRegistry loads tool adapters based on the active profile at boot. Each adapter wraps a ToolDef and registers its action type with the session’s action system. Profile filtering uses category-based matching against ToolDef.category.

#![allow(unused)]
fn main() {
/// Profile registry: resolves profile names to allowed tool categories.
pub struct ProfileRegistry {
    profiles: HashMap<String, HashSet<Category>>,
}

impl ProfileRegistry {
    /// Load tools for the given profile. Called once at startup.
    pub fn load_profile(&self, profile: &str) -> Vec<&'static ToolDef> {
        let categories = self.profiles.get(profile)
            .expect("Unknown profile");

        ALL_TOOL_DEFS
            .iter()
            .filter(|t| categories.contains(&t.category))
            .collect()
    }

    /// Load tools for composite profiles (e.g., "trader,vault").
    pub fn load_composite(&self, profiles: &[&str]) -> Vec<&'static ToolDef> {
        let mut categories = HashSet::new();
        for profile in profiles {
            if let Some(cats) = self.profiles.get(*profile) {
                categories.extend(cats.iter());
            }
        }

        ALL_TOOL_DEFS
            .iter()
            .filter(|t| categories.contains(&t.category))
            .collect()
    }
}
}

The two-layer tool model (8 Pi-facing tools wrapping ~423 underlying adapters) means context window cost is fixed regardless of how many adapters are loaded. The inference gateway’s L4 layer prunes these down to ~10-15 per request via semantic search.

Profile filtering happens once at extension initialization. All adapters matching the profile are available immediately. No per-request filtering, no session caps, no activation sequences.

Profile-to-category mapping

* conservative includes ~40 restricted write tools (no leverage, no complex LP, no flashloans).

Profile design notes

The active profile is the default for standard Golems. It includes nearly everything except testnet tools (not used in production). The full profile is identical in category coverage but is the canonical name for non-Golem power users.

The observatory profile is the Sleepwalker’s configuration: ~72 read-only tools, no wallet needed. The conservative profile sits between observatory (read-only) and active (full write) – it allows trades but blocks high-risk operations.

The data and observatory profiles include streaming because real-time price feeds and pool event subscriptions are read-only operations. Any profile that needs market awareness gets streaming automatically.

The trader and lp profiles both include safety because any profile that can execute on-chain writes must have safety middleware available for simulation, risk assessment, and token validation.

The learning profile includes intelligence in addition to memory. Self-improvement tools need intelligence tools (prediction comparison, regime classification) to function. It remains narrow – no trading, no LP, no write capability.

Approximate tool counts per profile

Counts are approximate because new tools are added per batch. The canonical source is ALL_TOOL_DEFS.len() at build time.