ARC
Pricing
Discord
Talk to an engineerStart free
Start free
ARCby FenxLabsCollective Intelligence

Platform

  • How it works
  • Custom routing and governance
  • Use cases
  • Example architectures

Deployment

  • Hosted Platform
  • Managed Service
  • Self-hosted Licence
  • For ISVs
  • Open the portal

Services

  • Assessment and planning
  • Architecture and integration
  • Model Adaptation
  • EU AI Act readiness
  • Managed Service operations

Resources

  • Cost modeller
  • Compare approaches
  • Pricing
  • FAQ
  • Transparency
  • Get started
  • Discord community

Legal

  • Privacy notice
  • Terms and conditions
  • Sub-processors
  • Accessibility

For individuals

  • FenxChat

FenxLabs. KvK 91762782.

Herengracht 320, 1016 CE Amsterdam, Netherlands

+31 85 060 5273contact@fenxlabs.ai

© 2026 FenxLabs. All rights reserved.

Write the rules for model and agent access

Define which models, tools and approved data sources each user, application or agent may reach. FenxARC™ applies your privacy, usage, routing and spending policy before it ranks a route.

Start freeTalk to an engineer

Free tier on the Hosted Platform. No card required.

Set the access boundary for each workload

A list groups the models, tools and rules approved for a team or use case. It defines what users, applications, workspaces and agents may reach before a request is classified or ranked.

Select who it governs

Assign users, teams, applications, workspaces, agents or use cases to the boundary designed for their work.

Approve the available resources

Choose the models, model groups, tools and data sources they are permitted to use.

Set the operating policy

Apply privacy, usage, budget and routing rules before each request runs. Cost can reorder approved routes but never relax access, privacy or capability.

Someone can have access to more than one list, and any single request runs inside one of them. Access is never pooled across lists.For agents, ARC controls the models, tools, approved data access, policies and spend available to a request. It does not control the agent's reasoning, planning loop, application logic, runtime or business accountability.
See how a request is handledEmbed ARC in your software
Workload rules

Turn business context into routing policy

Define the kinds of work your organisation recognises. ARC identifies when each category applies, then gives the request the right resources, handling and routing policy.

  1. 01Name the workloadUse the language your organisation already works with, from customer support to sensitive research.
  2. 02Define the matchSet the users, tasks, content and conditions that place a request in that category.
  3. 03Choose the treatmentAssign the list, resources, privacy handling, budget and routing objective for matching work.
Examples
  • Customer support
  • Marketing content
  • Legal review
  • Sensitive research
  • Internal analysis
  • Code assistance
  • First-pass triage
  • Contract review
  • Incident response
  • Employee casework
  • Investor updates
  • Site reports
  • Account plans
  • Classified work
  • Meeting notes
These are examples of tags a customer may define. ARC does not ship an understanding of your departments. You define the tag, the conditions that trigger it and the route it takes.

As priorities change, update the category, matching logic or destination centrally. Applications continue using the same ARC integration.

See it in your environment

You define what private means

ARC keeps privacy evaluation in the routing decision, but your organisation defines what private means. Apply that policy across model routing or to a specific list, and ARC enforces it before ranking a route.

Handling your policy can require

  • Route normally: No special handling
  • Private destination: Keep it inside the boundary
  • Redact: Remove what the next step does not need
  • Shield: State the task without the material
  • Decompose and recombine: Split the work, reassemble inside
  • Block: Refuse the request

Across model routing

At the model-routing level, the policy applies to everything your organisation sends through ARC.

On one list

On a list, the policy applies to that team or use case, so work that is more sensitive can be governed more tightly than the organisation as a whole.

A cost objective reorders routes that already meet your privacy policy. It cannot reach one that does not.

See how ARC makes routing decisions

Try a policy against real requests first

  1. 01

    Categories you define yourself, written as plain-text rules describing what counts and what does not.

  2. 02

    A test bench sits beside the rules. Run sample requests through a category and see how it classifies before it touches live traffic.

  3. 03

    A rule you write is evaluated from the day you write it, and whether it changes a routing decision is a separate switch. Watch it against real traffic before you let it enforce anything.

Keep policy consistent wherever ARC runs

Where ARC runs changes where handling executes, not which policy model you set. On the Self-hosted Licence, handling can run inside your environment before any external provider receives anything. Hosted ARC performs the same workflow inside a different trust boundary.

ARC governs what each provider receives. Retention and training are determined by the selected endpoint and its terms. ARC supports your compliance programme but does not replace it.
Explore the Self-hosted LicenceSee where ARC sits in real environments

Start with one policy boundary

Start free with one OpenAI-compatible integration. Talk to an engineer if access policy, data boundaries or deployment need to be settled first.

Start freeTalk to an engineer