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

Task-List Pagination Integrity Automation: When a Database's Own Row Ceiling Hides Data Behind a 200 OK

Centriu Run's task list used to fetch every task for an organization in a single request — which worked invisibly right up until an organization crossed 1,000 tasks, because the underlying database layer enforces a hard 1,000-row ceiling that wins silently over any larger request: the response still comes back as a normal, successful HTTP 200 with exactly 1,000 rows, with nothing in the response indicating anything was cut. A real measurement on the day of the fix found 1,607 tasks in one organization, of which 607 never reached the browser at all — because the list is ordered newest-first, the ceiling always consumed the oldest tail, so a "Completed Tasks" tab showing a partial slice of history was reporting itself as complete, and any task past the cutoff was unreachable from search entirely. The fix requests successive 1,000-row pages using the database layer's own range mechanism until a page comes back smaller than a full page — the only way to know for certain nothing is left — with an explicit ceiling at 50 pages (50,000 tasks) so a pathological organization can't make the list load indefinitely; hitting that ceiling logs a warning and stops cleanly rather than looping forever.

Task-List Pagination Integrity Automation: When a Database's Own Row Ceiling Hides Data Behind a 200 OK

Why a single unpaginated query is invisible right up until it silently isn't

A single query with no explicit pagination looks completely correct in every test performed against a smaller dataset — it returns exactly what's asked for, with a normal success response, because the actual row count never gets anywhere near whatever hidden ceiling the underlying database platform enforces. The defect has no failure mode that looks like a failure: no error, no partial-content status code, nothing distinguishing a complete result from a truncated one. It only becomes visible once a real organization's data volume crosses that ceiling — and by then, the missing data has already been silently missing for however long it took to get there.

  • A single query with no explicit pagination looks completely correct in every test performed against a smaller dataset — it returns exactly what's asked for, with a normal success response, because the actual row count never gets anywhere near whatever hidden ceiling the underlying database platform enforces. The defect has no failure mode that looks like a failure: no error, no partial-content status code, nothing distinguishing a complete result from a truncated one. It only becomes visible once a real organization's data volume crosses that ceiling — and by then, the missing data has already been silently missing for however long it took to get there.

How Centriu Run found and closed the gap, with a real measurement behind it

The defect was found by direct production measurement, not a code review guess: at the agency running the check, the organization had 1,607 tasks in total, and the single unpaginated request was silently returning only the first 1,000 of them — 607 tasks, comprising 463 completed and 12 still active, never reached the browser at all. Because the underlying query orders tasks by delivery date descending, the row ceiling always consumed the oldest tail of the list first: a "Completed Tasks" tab was displaying a partial slice of the organization's actual history while presenting itself as the complete record, and any task older than the silent cutoff simply did not exist as far as any search or filter in the product could tell — not slow to find, genuinely unreachable.

The root mechanism is specific to the database platform itself, not a bug in the application's own query logic: Supabase's PostgREST layer enforces its own `max-rows` setting (1,000 by default) that overrides any larger request automatically — the response still comes back as a completely normal, successful HTTP 200, with the row count simply capped and nothing in the response body or status code distinguishing a capped result from a genuinely complete one. A query written to ask for everything in one call has no way to detect this on its own; it looks identical whether the real total is 900 rows or 900,000.

The fix replaces the single request with a loop that requests successive pages of up to 1,000 rows each, using the database layer's own range mechanism to specify which slice of rows each request should return, continuing until a page comes back with fewer rows than the requested page size — the only reliable signal that nothing is left to fetch, since a full page could always mean there's more. An explicit ceiling stops the loop at 50 pages, a deliberate limit of 50,000 tasks per organization: the code comment accompanying it is direct about the reasoning — if an organization's task count ever gets that large, that scale is a different problem to solve deliberately, and a task list screen silently trying to load an unbounded number of rows forever is not where that problem should be discovered. Hitting that ceiling logs a specific warning rather than failing silently or looping without end.

What is actually built today

  • A paginated task-retrieval loop requesting successive 1,000-row pages via the database layer's own range mechanism, replacing a single unbounded request.

  • A completion check based on receiving a page smaller than the full page size — the only way to confirm nothing further remains, rather than assuming a full first page means the whole list.

  • An explicit 50-page (50,000-task) safety ceiling preventing an unbounded loop for a pathological organization, with a logged warning if that ceiling is ever reached.

  • The fix scoped specifically to the task-retrieval query identified as affected — confirmed via the same commit's own diff, not a platform-wide rewrite touching unrelated queries.

  • A defect measured and quantified in real production data before the fix (1,607 total tasks, 607 previously unreachable) rather than addressed as a purely theoretical risk.

  • No change to the task ordering itself (still newest-first by delivery date) — the fix corrects completeness of retrieval, not the display order users already expect.

What changes operationally

A task list, once an organization's history is large enough to have silently hit the platform's row ceiling, actually returns everything it claims to — a "Completed" tab that says complete now genuinely is, and a search for an older task can actually find it. And because the defect had no visible failure symptom (a normal 200 response, no error, no obviously wrong count for a smaller organization), the value here specifically is closing a class of defect that data volume alone would otherwise have kept hidden indefinitely for a smaller organization and silently active for a larger one.

  • A task list, once an organization's history is large enough to have silently hit the platform's row ceiling, actually returns everything it claims to — a "Completed" tab that says complete now genuinely is, and a search for an older task can actually find it. And because the defect had no visible failure symptom (a normal 200 response, no error, no obviously wrong count for a smaller organization), the value here specifically is closing a class of defect that data volume alone would otherwise have kept hidden indefinitely for a smaller organization and silently active for a larger one.

A completed task from months ago, findable again (illustrative scenario, not a real client)

Someone searches for a specific task they know was completed several months earlier, in an organization with well over a thousand total tasks. Before the fix, that task simply wasn't present in the data the browser ever received — the search wasn't broken, the data behind it was silently incomplete. After the fix, the same task is retrievable, because the full task history is paged through completely rather than cut off at the platform's row ceiling.

A completed task from months ago, findable again (illustrative scenario, not a real client)

Como começar

Perguntas frequentes

What was the actual measured impact of this defect?

At the organization where it was measured, 1,607 total tasks existed, of which 607 (463 completed, 12 active) never reached the browser — silently cut off by the database platform's own 1,000-row ceiling.

Why didn't this show up as an error?

The database platform's row ceiling overrides a larger request automatically, and the response still comes back as a completely normal, successful HTTP 200 with the row count simply capped — there is no error signal to catch.

How does the fix know when it has actually retrieved everything?

It requests successive 1,000-row pages until a page comes back with fewer rows than the full page size — the only reliable signal that nothing further remains.

Is there a limit to how many tasks this can retrieve?

Yes, a deliberate ceiling at 50 pages (50,000 tasks) stops the loop and logs a warning, specifically so an extreme data volume can't make the list load without bound.

Which tasks were affected — old ones or new ones?

Because the list is ordered by delivery date descending, the ceiling always cut the oldest tail of the list first — older tasks, including completed ones, were the ones going missing.

What does Centriu Run cost?

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

See how Centriu Run guarantees a complete task list, not just a fast one

Centriu Run's task list used to fetch every task for an organization in a single request — which worked invisibly right up until an organization crossed 1,000 tasks, because the underlying database layer enforces a hard 1,000-row ceiling that wins silently over any larger request: the response still comes back as a normal, successful HTTP 200 with exactly 1,000 rows, with nothing in the response indicating anything was cut. A real measurement on the day of the fix found 1,607 tasks in one organization, of which 607 never reached the browser at all — because the list is ordered newest-first, the ceiling always consumed the oldest tail, so a "Completed Tasks" tab showing a partial slice of history was reporting itself as complete, and any task past the cutoff was unreachable from search entirely. The fix requests successive 1,000-row pages using the database layer's own range mechanism until a page comes back smaller than a full page — the only way to know for certain nothing is left — with an explicit ceiling at 50 pages (50,000 tasks) so a pathological organization can't make the list load indefinitely; hitting that ceiling logs a warning and stops cleanly rather than looping forever.