Core concepts

Flexor is built on four primitives. Everything else in the system is composed from these four. Understanding them - and how they relate - is the prerequisite for operating Flexor effectively.

Vaults

A vault is a structured directory. It holds the configuration, rules, skills, agents, and knowledge that define how Flexor behaves in a given context.

Vaults are organized into four tiers:

Tier	Scope	Who manages it	Examples
L1 - Platform	Flexor itself	PLEXI	Core skills, system prompts, default behavior
L2 - Company	Your organization	Your team	Fund-level rules, shared agents, shared skills
L3 - Personal	An individual operator	That operator	Personal preferences, experimental configs
L4 - Project	A specific workflow or initiative	Project owner	One-off agents, temporary automation, client deliverables

When Flexor resolves a configuration value, it reads from L4 first, then L3, then L2, then L1. A lower tier can override a higher tier. A company-level rule can be overridden by a personal preference; a project-level agent can reference company-level skills without re-defining them.

This hierarchy is what makes Flexor scalable across a firm: one principal can configure shared skills at L2, and each operator uses them at L3 or L4 without duplication.

Skills

A skill is a reusable unit of work. It takes inputs, executes a defined sequence of actions, and returns outputs.

inputs → [step 1] → [step 2] → [step 3] → outputs

Skills can:

• Query a data source
• Apply a transformation
• Make a decision (conditional logic)
• Send a notification
• Write to the audit log
• Call another skill

Skills are stateless. They do not persist state between invocations. State lives in the vault or in the data systems skills interact with.

The standard skill library covers the most common fund-operations actions: data catalog queries, feed freshness checks, notification dispatch, audit logging, report formatting, and more. Custom skills are YAML files you write and place in your company or project vault.

Agents

An agent is an orchestrator. It watches for a trigger, then executes a task sequence using skills.

An agent definition has three parts:

1. Trigger - when to run. Options: schedule (cron), event (data event from PlexiFact), webhook (HTTP call), or manual.
2. Tasks - what to do. An ordered list of skill invocations, with optional conditional execution.
3. Metadata - name, description, owner, environment, and audit settings.

Agents are not functions. They are operational processes. Design them with the same care you would apply to a documented runbook: clear trigger, predictable output, explicit failure handling.

Knowledge base

The knowledge base is the memory layer. It is a searchable collection of documents - policies, procedures, data dictionaries, decision frameworks - that agents can query at runtime.

When an agent needs to answer a question (“which LP notification threshold applies to this fund?”), it queries the knowledge base and uses the result to shape its output.

The knowledge base supports two types of content:

• Structured facts - key-value pairs and tables with explicit fields (e.g., fund parameters, threshold values)
• Unstructured documents - Markdown files, PDFs, procedural notes

The knowledge base improves over time. When an agent makes a decision and the outcome is confirmed (manually or via a downstream signal), the knowledge base logs the pattern. Over multiple iterations, it builds a record of what worked - a machine-readable version of the firm’s operational judgment.

How the four primitives compose

Vault (L2 - company)
├── skills/
│   └── data-freshness-check.yaml    ← skill definition
├── agents/
│   └── feed-monitor.yaml            ← agent definition (uses the skill above)
└── knowledge/
    └── feed-sla-thresholds.md       ← knowledge document (agent queries at runtime)

The agent runs on a schedule. It calls the skill. The skill returns a result. If the result is anomalous, the agent checks the knowledge base for the applicable SLA threshold, then decides whether to fire an alert. The audit log records the decision.

This is the complete loop: trigger → skill → knowledge → action → audit.

What Flexor is not

• Flexor is not a data storage system. It orchestrates access to data that lives elsewhere.
• Flexor is not a business intelligence tool. It does not produce visualizations or dashboards.
• Flexor is not a general-purpose programming environment. It is designed for operational workflow automation, not software development.
• Flexor is not a replacement for your data team. It augments operators by handling the recurring, rule-bound work so the team can focus on judgment-intensive tasks.