Pular para o conteúdo
Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Painel ilustrativo do Sistema Centriu com sete frentes trabalhando: atendimento, comercial, operação, agentes, inteligência, conteúdo e marketing. Cada frente mostra o trabalho concluído ou o próximo passo.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

  • Sistemas que não se falam

    O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.

  • Dados duplicados

    Ninguém sabe qual versão é a verdadeira na hora de decidir.

  • Conversas perdidas

    O cliente repete o contexto a cada canal e a cada pessoa.

  • Tarefas espalhadas

    O trabalho vive em planilhas, mensagens e na memória de alguém.

  • Decisões sem contexto

    A escolha é feita com o recorte que estava à mão, não com o que importava.

  • Automações desconectadas

    Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

  • Clientes
  • Comercial
  • Atendimento
  • Operação
  • Financeiro
  • Marketing
  • Inteligência
  • Agentes
  • Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando
Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Pular para o conteúdo

problema

Agent Benchmark Execution Honesty Gate Automation: A Score of 85-100, Guaranteed, Whether or Not the Agent Ran

Centriu Axiom's internal Benchmark tool scores how well the AI agent performs a test. This sets a baseline score. Later runs are compared to it to catch a regression, a problem. An internal audit found that "running" a benchmark never actually called the agent. A success rate was chosen randomly between 85% and 100%. Every expected output was then randomly marked as matching or not matching based on that rate. This means every benchmark scored between 85 and 100. This happened no matter if the agent worked correctly, was broken, or was never called. That score became a baseline. A later, equally random score was compared to it. This produced a "regression detected" or "no regression" verdict by pure chance. This was a false performance signal. It was used to decide if a change was safe to ship. The fix does not try to build the real execution engine as a quick patch. The code's own reasoning explains that doing so blindly, without properly connecting the agent's real pipelines, "would produce another layer of lies, just harder to find." Instead, running a benchmark today causes an error. It records the run as honestly failed, with no score. There is no baseline update. No regression check is done. The truth is that no execution ability exists yet. This is stated clearly instead of being faked.

Agent Benchmark Execution Honesty Gate Automation: A Score of 85-100, Guaranteed, Whether or Not the Agent Ran

A metric used to decide whether a change ships needs to measure something real

A benchmark score exists to answer an important question. Is this version of the agent good enough? Did the most recent change make it better or worse? Every decision made using that score depends on what the score actually measured. This includes setting a baseline, flagging a regression, or deciding if a change is safe to release. A benchmark score that is not based on the agent's real behavior does not help answer that question. It actively gives a wrong answer that looks correct. This is because a random number in a fixed range does not show that it is not connected to anything real.

  • A benchmark score exists to answer an important question. Is this version of the agent good enough? Did the most recent change make it better or worse? Every decision made using that score depends on what the score actually measured. This includes setting a baseline, flagging a regression, or deciding if a change is safe to release. A benchmark score that is not based on the agent's real behavior does not help answer that question. It actively gives a wrong answer that looks correct. This is because a random number in a fixed range does not show that it is not connected to anything real.

How Centriu Axiom chose an honest refusal over a hasty simulation

This problem came from the same internal audit. That audit fixed the Outcome Simulator's randomly-generated scores. It also fixed Axiom's two fake AI-recommendation failure paths. Both are on other pages of this pillar. This is the same basic pattern. Here, it applies to an internal engineering tool. It is not a feature for customers. The old code's own header comment was clear about what it was. It said: "this does NOT invoke the Axiom agent. It fabricates outputs from Math.random() to drive the scoring/UI demo." The Benchmark screen showed a matching "execução simulada" disclaimer. But, just like with the Outcome Simulator, the disclaimer stayed on the screen. The number it described did not. The fake score became a `baseline`. Every later run's equally fake score was compared to that baseline. This decided if a "regression" had happened.

The way the fake scores were made, directly from the removed code, was this: a success rate was chosen once per run. It was uniformly between 85% and 100%. This was `0.85 + Math.random() * 0.15`. Then, every true/false output the benchmark case expected was marked true or false. This was done by comparing a new random choice against that rate. The result is exact and always true. The success rate itself was never allowed to fall below 85%. So, EVERY benchmark run scored between 85 and 100. This was true no matter if the agent was working well, working badly, or never called at all. This was actually the case. A baseline was set from one random run. A later score from a second, independent random run then fed a real-looking regression calculation. Two random numbers being compared could produce "regression detected" or "no regression" by pure chance. This could happen in either direction. It had no relation to whether the agent had actually changed at all.

The team did not see the fix as a chance to quickly connect something that looked like real execution. Instead, the team made a clear choice. This choice is recorded directly in the fix's own reasoning. Building real benchmark execution needs to arrange the agent's actual pipelines. These include template application, sandbox execution, and guided generation. Each has its own real effects. It also needs to compare truly produced output against what the case expects. Trying to do that as a quick follow-up to this specific fix, without doing it correctly, would — in the fix's own words — "produce another layer of lies, just harder to find" than the one being removed. So the function that used to make fake outputs now does one thing. It causes an error. It states clearly that real benchmark execution is not yet ready. It also states that previous scores came from randomly made outputs. These never measured the agent at all.

The surrounding logic for recording runs was not changed by this fix. It already had a real try/catch around the execution step. This is read in full for context. When the execution function causes an error, the run is recorded with a `failed` status. The real error message is stored directly in that run's result record. This means a benchmark attempt today shows up honestly in the run history as a failure. It has a specific, truthful explanation. It does not disappear silently. It does not continue to show a fake score. This error happens before any score is calculated. So the regression check further down the line is never reached for a failed run. This check is the exact way a randomly generated baseline used to cause problems. So no fake regression verdict can be produced from it either.

What is actually built today

  • An clear, honest refusal happens whenever a benchmark is run. It is recorded directly as a `failed` run. It has a specific message stating that real execution is not yet ready.

  • No score is calculated. No baseline is set or updated. No regression comparison is done for a run that fails this way. The mechanism that could previously be corrupted by two independent random choices is never reached.

  • A run's failure and its exact reason are stored in that run's own history record. This is visible to anyone reviewing benchmark history. It does not disappear silently.

  • The randomly generated success-rate mechanism has been removed completely. This is the specific `0.85 + Math.random() * 0.15` calculation. It guaranteed every run scored 85 to 100. It was not just made smaller or hidden.

  • A clear decision was made. It is recorded directly in the fix's own reasoning. This was not to build a quick replacement execution engine as part of this same fix. This avoids a second, harder-to-find layer of fake information.

  • It is confirmed today by direct check. The refusal remains absolute. No real execution engine has replaced it since.

What changes operationally

A benchmark score, when one is eventually ready, will only come from watching the agent do something real. It will not come from a random choice disguised as a demo. In the meantime, a team looking at benchmark run history sees an honest, specific statement. It says that execution is not ready yet. This is instead of a healthy-looking number between 85 and 100. That number never meant anything. It could not have caught a real regression even by accident.

  • A benchmark score, when one is eventually ready, will only come from watching the agent do something real. It will not come from a random choice disguised as a demo. In the meantime, a team looking at benchmark run history sees an honest, specific statement. It says that execution is not ready yet. This is instead of a healthy-looking number between 85 and 100. That number never meant anything. It could not have caught a real regression even by accident.

A broken agent that finally scores like one (illustrative scenario, not a real client)

A change to the agent's pipeline causes a real regression, a problem. A step that used to work now fails completely. Before this fix, running the benchmark against that broken pipeline would still likely score between 85 and 100. This is because the score never depended on the agent actually being called. After the fix, running the same benchmark honestly fails. It is recorded as a failed run with a specific reason. It does not report a healthy score for a pipeline that no longer works.

A broken agent that finally scores like one (illustrative scenario, not a real client)

Como começar

Perguntas frequentes

Did the Benchmark tool ever actually run the AI agent to produce its score?

No — a success rate was chosen randomly between 85% and 100%. Outputs were marked matching or not based on that rate. The agent was not actually called at all.

Why did every benchmark score land between 85 and 100?

The random success rate that made the fake outputs was never allowed to fall below 85%. So every run scored in that range always. This was true no matter what the agent actually did.

Could this fabricated score actually mask a real regression?

Yes — a baseline set from one random choice compared against a later, separate random choice could report "no regression" or "regression detected" by pure chance. This was not related to whether the agent had actually gotten worse.

Why didn't the fix just build real benchmark execution right away?

The team's own stated reason is that doing so without properly arranging the agent's real pipelines risked making a second, harder-to-find layer of fake information. This would not be a real fix.

What happens when someone runs a benchmark today?

It fails honestly. It is recorded with a `failed` status. It has a specific message stating that real execution is not ready yet. No score, baseline, or regression check is produced.

What does Centriu Axiom cost?

It is sold by subscription with a published starting price. The exact current values are on the central pricing page.

See how Centriu Axiom is honest about what it can and cannot measure yet

Centriu Axiom's internal Benchmark tool scores how well the AI agent performs a test. This sets a baseline score. Later runs are compared to it to catch a regression, a problem. An internal audit found that "running" a benchmark never actually called the agent. A success rate was chosen randomly between 85% and 100%. Every expected output was then randomly marked as matching or not matching based on that rate. This means every benchmark scored between 85 and 100. This happened no matter if the agent worked correctly, was broken, or was never called. That score became a baseline. A later, equally random score was compared to it. This produced a "regression detected" or "no regression" verdict by pure chance. This was a false performance signal. It was used to decide if a change was safe to ship. The fix does not try to build the real execution engine as a quick patch. The code's own reasoning explains that doing so blindly, without properly connecting the agent's real pipelines, "would produce another layer of lies, just harder to find." Instead, running a benchmark today causes an error. It records the run as honestly failed, with no score. There is no baseline update. No regression check is done. The truth is that no execution ability exists yet. This is stated clearly instead of being faked.