AI Projects

AI Projects are the top-level organizational unit inside Fabrix.ai. Every agent you build—its toolsets, personas, prompt templates, observability, conversations, and governance policies—belongs to an AI Project.

An AI Project acts as an isolation boundary, ensuring clean separation between environments such as Development, Staging, Production, POCs, or customer-specific deployments.

1. What an AI Project Represents

An AI Project defines:

Capability	Description
LLMs	Select which Large Language Models the project can use.
Guardrails	Attach governance and safety models (e.g., Tümeryk, NeMo, IBM Granite).
Toolsets	The MCP tools that agents inside the project can call.
Prompt Templates	All the structured workflows and instructions available to personas.
Personas	Domain-specific agent behaviors and capabilities.
Access Policies	Regex-based permissions for which toolsets & templates a persona may use.
Spend Limits	Cost and token-consumption controls for the project.

Once a user opens a project, every view (Toolsets, Personas, Prompt Templates, Observability, Conversations) automatically reflects only that project's configuration.

Tip

For detailed information on toolsets and how to create them, see the Toolsets Guide.

Tip

For detailed information on personas and how to create them, see the Personas Guide.

Tip

For detailed information on prompt templates and how to create them, see the Prompt Templates Guide.

2. Creating an AI Project

When the user clicks AI Projects → Add, the project creation form appears.

The Add Project Form

Users must configure:

2.1 Project Metadata

Project Name (required) Human-friendly identifier (e.g., Salesforce, Network-Ops, AIOps-POC).

Description (required) Clear explanation of the project's purpose.

Label (optional) A visual tag to categorize or color-code the project in the UI.

2.2 Project Type

Projects can be classified as:

Development - For building, iterating, and testing agents.
Production - For stable, customer-facing or mission-critical deployments.

Project type influences internal routing and environment separation.

2.3 Spend Limits

Projects can optionally include daily / weekly / monthly token budgets for:

Total LLM token consumption
Cost enforcement
Auto-block rules
Warning & alert notifications

(These are displayed again inside Observability → Spend Limits.)

3. Selecting LLMs

Under the LLMs section, users must select one or more models the project is allowed to access.

The list includes entries like:

Name	Type	Description
gpt-4.1	llm	LLM based AI system
prod-claude-sonnet-4	llm	Claude Sonnet Production Model
gemini-2.5-flash	llm	Google Gemini Model
palmyra-x5	llm	AI21 Frontier Model

Users check the models they want to enable.

Important:

LLM selection controls both inference and tool-using agents.
A persona cannot call a model unless it is enabled at the project level.

4. Selecting Guardrails

Guardrails define safety boundaries and compliance rules that govern every agent in the project.

Examples:

Name	Type	Description
Tümeryk	guardrails	AI safety filter
NVIDIA NeMo	guardrails	NeMo-based guardrail system
IBM Granite Guardian	guardrails	Policy-based guardrail

You may choose zero or more guardrails.

5. Toolset & Prompt Template Access Policy

This JSON definition tells Fabrix.ai:

Which MCP Server the project uses
Which Toolsets are visible to personas
Which Prompt Templates they are allowed to load
How conversation optimization works

6. Opening an AI Project

When a user enters a project, they see the project-level workspace, where everything is scoped to the project:

Sections Available Inside a Project

Toolsets
Prompt Templates
Personas
Observability
Conversations
Spend Limits
Search
Models
Guardrails
External MCP Servers

At this point, users can fully configure and build agentic logic.

7. Project Actions

Each project card includes a contextual menu with the following options:

7.1 View Details

Shows high-level metadata, LLMs, guardrails, and policies.

7.2 Edit

Opens the same form as project creation, allowing full updates.

7.3 Clone

Create a complete copy of the project including:

All toolsets
All personas
All prompt templates
All access policies
All model & guardrail configurations

The user must provide a new project name & optional description.

This is widely used for staging-to-production promotion workflows.

7.4 Disable

Temporarily prevents any personas or users from executing within this project.

7.5 Delete (optional based on permissions)

Permanently removes the project.

8. Toolset & Template Importing (Local vs Imported)

Inside every AI Project, users can work with two types of Toolsets and Prompt Templates:

Local – created inside the current project
Imported – automatically pulled from other projects based on Access Policies

This mechanism allows teams to share reusable toolsets, templates, and workflows—while still preserving project isolation and override control.

8.1 Local Toolsets & Templates

Local entries are:

Created directly within the project by the user
Editable within the project
Owned exclusively by the project
Highest priority (override imported ones)

Local toolsets/templates appear under the Local tab.

Local toolsets support full CRUD:

Add new MCP toolset YAML
Edit existing toolsets
Delete or version them
Associate with personas

Local templates also support:

Full text editing
AI-assisted refinement (magic pencil icon)
Versioning & preview

8.2 Imported Toolsets & Templates

Imported toolsets and templates appear under the Imported tab.

They are brought into the project automatically when the Access Policy's regex matches:

"toolset_pattern": "aiops.*|common.*|network.*"
"prompt_templates_pattern": "incident_.*|visualization.*"

Imported resources:

Are read-only in the current project
Cannot be edited or deleted locally
Are always synchronized with the source project
Allow cross-project reuse of standardized automations

8.3 Precedence Rule (Local > Imported)

If a Toolset OR Prompt Template exists:

once in Local
and again in Imported

the Local version ALWAYS overrides the Imported version

This ensures that:

Teams can adopt global/shared resources from other projects
BUT still customize or override behaviors safely
Without needing to modify source projects
Or break shared logic for other teams

Example Scenario

If another project exports:

toolset: aiops
tool: get_alerts

And the current project defines its own version:

toolset: aiops
tool: get_alerts

Then the local version is the only one visible to personas, ensuring deterministic behavior.

8.4 Why Importing Exists

The import system supports:

Shared Tooling - Teams can centrally maintain: AIOps toolsets, Network automation toolsets, Diagnostic pipelines, Shared business workflows. And share them across multiple projects.
Enterprise-grade Governance - You can maintain: Production-approved toolsets, Standardized prompt templates, Controlled escalation logic. And allow downstream teams to consume them safely.
Safe Custom Overrides - Teams can override shared resources safely without breaking anyone else.

8.5 Summary

AI Projects can use both local and imported toolsets/templates
Imported resources enable cross-project reuse
Local resources always override imported ones
Users can safely customize without breaking shared logic
Importing is governed through regex access policies

9. Why AI Projects Matter

AI Projects ensure:

Isolation - Each project has: its own tools, its own personas, its own templates, its own LLM access, its own history.
Governance & Compliance - Policies and guardrails are enforced per project.
Cost Separation - Spend limits apply individually.
Safety - Regex-based access patterns ensure personas cannot access tools or templates outside their allowed domain.

10. Summary

AI Projects are the foundation of your agent ecosystem inside Fabrix.ai.

They define the models, tools, safety rules, and workflows your agents will use. Every agentic feature is project-scoped, enabling safe, isolated, enterprise-grade AI operations.