Skip to content

Core principles ​

Workflows over prompts ​

Don't build one complex prompt. Build a workflow instead.

Complex prompts tend to accumulate instructions, context, branching logic, exceptions, and validation rules. This makes them harder to understand, more expensive to run, and less predictable.

Faimulus moves this complexity into explicit workflows composed of smaller, focused steps.

Explicit over implicit ​

Important behavior should be visible in the workflow rather than hidden inside prompt instructions.

Branching, validation, retries, tool calls, permissions, and external interactions should be modeled explicitly whenever possible.

This makes workflows easier to understand, inspect, test, and change.

AI where it adds value ​

AI is not the answer to every problem.

Use AI for tasks that require reasoning, interpretation, classification, or generation. Use deterministic logic where deterministic logic is sufficient.

A workflow should rely on an AI model only when the flexibility of AI provides a clear benefit.

Small, focused steps ​

Each step should have a clear responsibility.

Breaking complex tasks into smaller nodes reduces the amount of context each AI call needs and makes failures easier to understand and handle.

Small steps also make workflows easier to reuse, test, and evolve.

Keep the core small ​

Faimulus is intentionally designed as a foundation rather than an all-in-one platform.

The core focuses on executing workflows. Capabilities such as AI models, memory, communication channels, and external integrations are provided through drivers and other extensions.

Replaceable infrastructure ​

Faimulus should not depend on a particular AI provider, memory implementation, communication channel, or external service.

Drivers provide these capabilities behind well-defined interfaces, allowing installations to choose the infrastructure that best fits their needs.

Semantic model roles over vendor model names ​

Workflows should request model behavior by semantic (logical) role, not by provider-specific model identifier.

Use role names such as general, router, summarization, classification, or extraction to describe intent. Map those roles to concrete provider instances and model IDs in workspace configuration.

This pattern keeps workflow YAML portable and reviewable, supports safe model swaps and staged upgrades, and avoids scattering vendor naming details throughout business logic.

Models can decide, workflows stay in control ​

AI models can make decisions within a workflow.

In practice, this often means selecting tools, classifying input, evaluating alternatives, or choosing among available paths.

These decisions can influence what happens next, but only within boundaries defined by the workflow. The workflow determines which choices are available, which capabilities the model can use, when external input or permission is required, and how execution proceeds after a decision is made.

The model provides flexible reasoning. The workflow remains the final authority over what the system actually does.

Documentation for the current repository state.