How Factorial Built An Agent Inside Their Platform That Respects Permissions

Factorial CEO Jordi Romero saw a problem everywhere he looked: Factorial's customers were exposing sensitive data to save time.

HR managers were pasting employee salary data into ChatGPT. Finance teams were uploading expense reports to Claude.

Worse, this analysis was often wrong. Outside models lacked important context about the company and its processes.

Factorial's clients wanted the power of AI, but they needed it inside their HR platform.

The company and the project

Founded in 2016, Factorial is a Barcelona-based, all-in-one HR platform serving more than 14,000 companies with nearly a million employees.

Valued at over $1 billion, Factorial handles everything from payroll and performance reviews to time tracking, expense management, and IT.

In 2025, they made it their mission to develop ChatGPT-like intelligence that works directly with company data.

"We don't want your employees to hand your data to an AI tool," Romero told customers. "We think the right thing is to put AI in the center of your data."

They started working on One — an AI agent living inside their platform.

The goal was to help managers and HR admins better understand their teams just by asking in natural language. And, to help employees get clarity on company policies and their own data ("how many PTO days do I have left?").

Choosing a language and a framework

Romero turned to CTO Ilya Zayats. Zayats wanted an architecture that was flexible enough to move fast while still solving underlying fundamentals.

Factorial's Ruby-on-Rails backend and React/TypeScript frontend pointed to something TypeScript-native.

Mastra provided the API layer, workflow abstractions, and LLM provider integrations the team needed — handling provider discrepancies and fundamentals like a memory layer so the team could focus on business problems rather than infrastructure.

Confronting the challenges

There were a few challenges with building an agent of this complexity:

• Permissions: Factorial has hundreds of granular permissions — who can see salary bands, approve expenses above certain thresholds, or access performance reviews from specific departments. These permissions are core to the product. Any AI solution that bypassed them would be immediately rejected by clients.

• Hallucinations: Factorial is a company tool, so any response from One could be treated as official communication.

• Wide product surface area: Factorial has more than 16 internal products covering different business processes. One needs to understand all of them in detail and know how to fetch data and execute actions across them all. Context size and needle-in-the-haystack retrieval were the primary limitations to solve.

Important product decisions

The team made some product decisions that would help solve these challenges:

• Permissions: The agent must operate with the same permissions as the logged-in employee, ensuring it doesn't have access to data it shouldn't. If a user can't see a particular salary number, neither can the AI. Raw data is never exposed, and this separation must be enforced at the architecture level, never relying on prompts.

• Hallucinations: If the agent doesn't have full clarity on the data or lacks the data to back up the answer, it must respond "I don't know, please ask a human"—never invent an answer.

Optimizing the agent

Ilya led a senior team of early adopters to design an architecture that would solve all of these issues. They decided to:

1. Treat the agent as another client application: The agent calls the same GraphQL API that powers Factorial's frontend. By treating the agent as another client, permission enforcement is automatic. There is no separate access control layer, and no drift between what users can see and what AI can access.

2. Move from dynamic schema to deterministic tools: The initial approach allowed the agent to dynamically discover the GraphQL schema and create queries on the fly. That idea was quickly discarded as the agent often went in the wrong direction, hallucinating parameters or getting into loops. All API fetching was moved to deterministic tools. The agent is now responsible for picking the right business concept and providing high-level params (filters and foreign keys), based on underlying query templates. This concept discovery happens dynamically, and the result includes not only the JSON schema of params but also extra context and usage examples, allowing the LLM to deeply understand the area it's being asked about. The format is very similar to Anthropic's skills system, and it eliminated an entire class of hallucinations.

3. Optimize data representation: The team discovered that TSV (tab-separated values) outperformed JSON by using 30-40% fewer tokens while actually improving recall rates. They pass TSV with a separate block of field descriptions, ensuring the LLM has a full understanding of what the returned data really means.

4. Build generative UI with shared state: The team wanted to solve more use cases than just data retrieval. Using CopilotKit's useCoAgent functionality, Factorial shares state between the frontend and the agent. Engineers and users can watch the agent build forms and surveys directly in the browser in real-time, greatly reducing manual interactions.

5. Implement enterprise observability: The team started with Braintrust for AI tracing and built extensive evals.

All of this is orchestrated with a Mastra workflow that uses an LLM to route to the right agent branch.

When users ask follow-up questions, the system maintains context and reuses the previous results. The workflow was the best pick, as it allowed the team to clearly debug LLM decisions and guide them properly to the right branch, shrinking the context and the breadth of each task.

What's next

As the calendar turns to 2026, the team is moving Factorial's agent beyond generating reports and building presentations.

The next big step is to bring determinism to user workflows while keeping the flexibility of AI for parts that can't be fully deterministic: expenses and travel policies, approval flows, and procurement flows. The goal is to save tens of hours per week for thousands of companies across the world.

As they develop, the team is constantly adjusting the agent architecture to ensure it can scale to the size of Factorial. Users expect magic from AI from day one, so the bar is very high.

With general availability set for January, Factorial has built exactly what their customers demanded: on-demand intelligence that keeps sensitive user data safe.