DB1 Itênex
BRENES
Talk to a specialist
DB1 Itênex product · Clovis Agentic

Agentic Software Engineering without giving up expert control.

Meet Clovis, our AI agent orchestration tool that keeps decisions and generated code governed and reliable across the whole development cycle, from discovery to deploy.

Works with the AI your team already usesAsks before it decidesDocumented and traceable

Who uses it

  • BRK

    Migration 4x faster, at 60% of the cost

  • MAG

    From idea to documented solution in 1 week

  • Votorantim

    Sharper impact analysis since Clovis came in

  • CrediSis

    9x more team deliveries in 4 months

The problem

Your team already uses AI to code. But does it control what the AI decides?

The AI tool is no longer the problem.

Your team already has one. Splitting work into stages and generating documents also exists, often for free.

Speed without method turns into rework.

AI fills whatever nobody explained with its most likely guess. The mistake shows up later, in production.

More AI is not always more results.

Part of the market wins when AI consumes more, not when it delivers better.

In your team's day to day

The request arrives half done

With no dedicated analyst, the card is written in a rush during planning. The developer starts with doubts and the meeting turns into a writing session.

The AI decides what was yours to decide

Business rules, an old system bug, what to keep and what to delete: it chooses on its own, and nobody finds out.

Knowledge leaves with the conversation

What the AI learned about your business stays in a chat that disappears at the end of the day. Documentation, when it exists, comes later.

AI does not lack capability.What is missing is control over the decisions it makes and consistency in the artifacts it produces.That is what Clovis does.

What Clovis does

Three ways to work with AI, always with you in control.

01Discovery

From a vague idea to a ready requirement.

You describe the need in your own words. Clovis asks the right questions and returns a document the whole team understands.

  • Short questions, with options to choose from
  • What you do not know becomes an open item, not an assumption
  • The document goes straight to Confluence, Jira or Azure DevOps
“For the first time we could start the sprint with well-structured cards, with context, goal and acceptance criteria defined. Planning got shorter and focused on what matters: prioritizing and planning.”
MAG squad, with no dedicated analyst
For the technical team
  • The document comes out in 11 sections: context, goal, scope, actors, business rules, flows, edge cases, acceptance criteria, glossary, technical open items and open questions.
  • Each of your answers is marked in the document. A technical decision is logged as an open item for the tech lead, without interrupting whoever is describing the business.
  • It requires no previous stage: you can start here on any project.

02Free conversation

Ask the system before you change it.

An open conversation about your code, to understand how something works today, plan a change and, with your approval, carry it out.

  • Understands systems nobody documented
  • Shows the plan before changing anything
  • Works on any project, with no preparation
At MAG, reading the code of services owned by several teams brought together in a single map, in the same week, the integrations the new assistant needed.
MAG
For the technical team
  • Agent mode: investigates, edits and runs commands, with no restriction.
  • Plan mode: read only. Presents a plan for you to review before telling it to execute.
  • The conversation is transient by design: what steers the project lives in a versioned file, not in a chat history.

03Coding with observability

You follow every step. And decide what is yours.

From analysis to delivered code, you see what the AI is doing, and it stops and asks whenever the decision is a business one.

  • What to build is written down before the code
  • Each of your decisions is recorded for the next deliveries
  • It ends in a delivery ready for review
At Votorantim, while specifying a change to the cashback program for retailers, Clovis mapped flows the initial analysis had not considered and raised the right questions before the code.
Votorantim
For the technical team
  • Four chained stages (Discovery, Preparation, Specification and Implementation), each with a specialized agent and its own context. In Discovery, several agents investigate in parallel.
  • Before the code come the specification, the plan, the test scenarios and the tasks. Human decisions live in their own file and apply to every agent that follows.
  • A mismatch between documentation and code becomes an escalated decision, never a silent fix. The cycle ends in a Pull Request.
The four coding stages, in detail

Clovis runs stages 1 to 4 of the Core Up method, from Discovery to Implementation. Each agent works with its own context and produces the input for the next stage. Stage 5, Runtime Intelligence, follows the system in production.

Stage 01

From an abstract intention to a map of business domains.

In

  • The code to analyze, and the path to the legacy system when there is one
  • Business rules and documentation: free text, files, URLs or MCP spaces (Jira, Confluence, wiki)
  • System type and critical constraints: target stack, contracts to preserve, fixed schema, test requirements

Does

  • Investigates the legacy code or the business documentation on several fronts at once
  • Correlates screens, endpoints, tables and rules to identify bounded contexts: business domains, not folder structure
  • Cites the evidence for each inference and rates its confidence
  • Escalates as a decision anything the evidence does not support

Out

  • The functional map: the domains, the dependencies between them and the suggested implementation order
  • The discovery memory: declared constraints and the record of human decisions, which take precedence over the code's behavior for every agent that follows
  • The list of domains to document and the technical skills to generate

Stage 02

The abstract intention becomes authoritative documentation.

In

  • The functional map as the starting point
  • The discovery memory, reread for each domain
  • The list of domains, which sets the order of work
  • The legacy code, when available, or the business documentation

Does

  • Generates lean global project instructions: stack, structure, conventions and the real build and test commands
  • Documents each domain in depth: schemas, field-by-field validations, edge cases, error handling
  • Generates the cross-cutting technical skills: architecture, testing, API documentation, security
  • Checks at the end that every cross-cutting decision has a concrete place in the documentation

Out

  • One skill per domain, which becomes the source of truth for the business: it describes the expected behavior, independent of framework and library
  • The repository instruction files, read by any coding agent that joins the project
  • Reusable technical skills

From here on the legacy system is no longer read. Whatever the documentation lacks becomes a question for a human.

Stage 03

From business knowledge to an executable plan.

In

  • The domain skill as mandatory context, the functional map and the project instructions
  • The chosen operation: a whole domain, an evolution of a domain, a multi-domain feature, a specification bug or an implementation bug
  • The description of the feature or bug in free text, with reference documents

Does

  • Works from the domain documentation, not from the legacy system, and produces everything in one sequence, without losing context from one part to the next
  • Surveys the current code to state what already exists and what is missing
  • Keeps the same format in everything it generates, through a versioned authoring standard
  • Creates an explicit task to update the documentation when documented behavior changes, and it is always first in line

Out

  • The specification: what needs to exist and why, with the business rules that apply
  • The execution plan: how to build it, what to reuse and what is missing
  • The test scenarios, each with its own identifier, to validate the delivery end to end
  • The tasks, with declared dependencies, each one delivering complete behavior

Stage 04

Runs in batches, with supervision after each batch.

In

  • The spec to be implemented
  • The pending tasks selected by a human
  • A warning about any missing dependency before it starts

Does

  • Implements the selected tasks: the coding agent decides what to do together or separately
  • Finds on its own the documentation and artifacts it needs to open
  • Writes code and tests, runs the project checks at the end and marks each task as done

Out

  • Code and tests in the repository
  • Updated documentation and a spec closed by human decision. The task list records the agent's work; the closing records the approval
  • With the spec closed, the cycle restarts at Specification (next unit) or at Discovery (new domain), now on code that already exists

A mismatch found at this point between documentation and code becomes an escalated decision, never a silent fix.

Also in Clovis

Code review

Reviews a Pull Request or two branches, and you choose which comments to publish.

Opening a Pull Request

Writes the title and description from the changes and only publishes with your approval.

Where it fits

It is not one more AI to hire. It is the method that secures the results of the one you already have.

  • You decide

    Business rules, what to do about an old system bug, what goes in and what stays out.

  • Clovis organizes

    Splits the work into stages, gives each agent only what it needs and sets where to stop and ask.

  • Your team's AI executes

    The coding agent your team already uses keeps reading the system and writing the documentation and the code.

  • Your repository keeps it

    Requirements, decisions and documentation live in files, next to the code. If you ever stop using Clovis, it all stays with your company.

Management and governance

Clovis Cockpit: governance carried out in real time.

AI agents only work at scale when someone can see what they are doing. In the Cockpit, every session, every decision and every token consumed is visible, traceable and under your team's command.

Clovis Cockpit dashboard with indicators for consumption, sessions, specs, tasks, code reviews, acceptance rate and pull requests, and consumption by organization, project and stage.
Consumption, delivery and quality side by side
By agent, model, project and stage
Who uses it

Named clients, results with numbers.

Sanitation · portal migration

BRK

4xfaster than the traditional method, at 60% of the cost

BRK was arriving in a new city and needed to migrate a portal in production, in a service 16 million people depend on. The migration started with a technical specialist supported by Clovis, and delivered:

  • The portal migrated in 1 month with 3 people, where the traditional method required 4 months with 5
  • The same quality and security expected of an essential service
  • The first agentic engineering delivery on a real BRK portal
Read the full case

Insurance · AI assistant for brokers

MAG

1 weekinstead of 7 to 10 weeks, the estimate without AI

Brokers would talk to an assistant to get product recommendations, simulate amounts and track their portfolio and commissions. In one week, one senior person delivered:

  • A prototype connected to the real services, which confirmed feasibility
  • Three architecture paths evaluated, with the reasoning behind the choice
  • Documentation split by workstream, so the team could build in parallel

Cashback program for retailers

Votorantim

Sharperimpact analysis, according to our team on the project

While specifying a change to the program, Clovis mapped the affected flows, including those the initial analysis had not considered, and raised the questions to answer before the code.

Credit cooperative

CrediSis

9xmore team deliveries, from July to October 2026

11Jul
23Aug
67Sep
98Oct

Deliveries per month since Clovis arrived. The average per person rose from 7.5 to 27.6.

Two more projects, opened up from the inside
Case AAbout 1 month for a pair, the conventional way.

Legacy modernization

A SilverStream system, with its source code stored inside the database, rewritten as a TypeScript monorepo.

3

days of work

4

domains delivered

21

tasks completed

4

escalated decisions

The starting point

  • Java backend and HTML frontend stored as records in database tables. There was no repository to clone and no file to open.
  • The business data model lives in a database with 4 schemas; the legacy code, in another.
  • Declared constraints: schema preserved, screen flow compatible with the legacy system and test coverage above 95%.

The targetTypeScript monorepo: Node/Express with SQL Server and Clean Architecture, React/Vite frontend with Tailwind.

What made the work different

  • Read the Java classes and HTML pages from inside the database tables and rebuilt both screen flows, linking each screen to the views and tables it queries.
  • Documented each domain before implementing: schema, field-by-field validations, messages and edge cases. With the technical ones, the repository closes with 33 skills.
  • 42 test files, about 1 for every 6 code files, written alongside the code and not afterwards.
  • 70 versioned documents, about 13,700 lines.

The decision that went to a human

The anomaly that was neither copied nor silently fixed

While documenting, the agent found a defect in the legacy system: saving a multiple-choice answer deleted every graduate's answers to that question and reinserted only those of the person answering. It did not reproduce it by imitation or fix it on its own. It escalated, which became three paths and a wait. The human decision was to scope the deletion to the person answering, and the documentation keeps the contrast with the legacy system so nobody copies it again.

Without governance: The agent would have replicated the defect by imitation, or fixed it silently, without anyone knowing. The business rule would have stayed only in the head of whoever read the code.

Case BAbout 3 weeks for a pair, the conventional way.

The schema as the requirement

A database schema as the only source of requirements, turned into a complete backend and frontend.

2

days of work

3

domains delivered

24

tasks completed

7

escalated decisions

The starting point

  • A single schema with 4 tables: donation pledges, their types, states and statuses.
  • No requirements document, user story or reference screen. The expected behavior only existed implicitly in the columns and constraints.
  • On the code side, only the skeleton of the two stacks: no domain, authentication or business rules.

The target.NET 10 backend with EF Core and SQL Server in clean architecture, Angular 22 frontend with Angular Material.

What made the work different

  • Looked for evidence in the configuration files to support what it stated about stack, commands and structure, instead of guessing from folder names.
  • Left the ambiguities marked as pending until a human answered, instead of resolving them on its own.
  • Each spec states what already exists and what is missing; each test scenario comes with its own identifier and an explicit expected result.
  • 66 test files and 98 scenarios tied to the tasks that created them, and 116 versioned documents.

The decision that went to a human

The entity the schema did not foresee

Each donation pledge pointed to the person who donated, but that table did not exist in the schema. The agent neither invented the entity nor ignored the reference: it escalated. The human decision was to create it with the foreign key, which added a whole domain to the project. Other gaps took the same path: whether the category's minimum amount guides or blocks, what the system does with the recurrence flag, and how to store passwords.

Without governance: Four gaps in the schema would have received four plausible answers that did not match each other. The missing entity would have been invented or ignored, and the choice of a central dependency would have been made by inertia.

The speed that showed up and the cost that came down.

  • BRK case4 months with 5 people1 month with 3 people
  • MAG case7 to 10 weeks (estimate without AI)1 week of 1 person
  • Case A~1 month for a pair3 days of work by 1 person
  • Case B~3 weeks for a pair2 days of work by 1 person

The governance that got stronger.

  • 39 ambiguous points became questions for a human across the three projects
  • Business rules, domain boundaries, legacy defects and architecture choices: none was settled by assumption
  • None of these questions delayed the delivery
How to start

Use Clovis with our team or directly in yours.

Agentic SDLC Consulting

With our team

Senior engineers build the method with your team on a real project, using Clovis. At the end, the method stays with you.

See the consulting

Clovis Agentic

In your team

Your team uses Clovis with the AI it already has. Start with a live session on your own code.

Clovis was born in our consulting projects. It is the same tool our team uses every day for clients.

Frequently asked questions

What people usually ask

Do I need to hire the consulting to use Clovis?

No. You can use Clovis directly in your team, with the AI you already have. If you want help building the method together with your team, the Agentic SDLC Consulting does that on a real project, using Clovis.

Does Clovis replace the AI my team already uses?

No. It works with the coding agent your team already uses, such as Copilot, Cursor or Claude Code. Clovis organizes the work, decides what each agent sees and sets where you come in. That is why there is no need to approve one more AI subscription.

Can people who do not code use it?

Yes, in Discovery. It was built for people who know the business: you describe the need in your own words, answer short questions and receive a requirements document ready for the team. You can publish it straight to Confluence, Jira or Azure DevOps.

How much supervision does this require from the team?

Supervision happens where the decision is yours, not on every line of code. Analysis, documentation and code arrive ready for review. Across three projects, 39 questions were taken to a person, and none delayed the delivery.

Where does what it produces live? And if we stop using it?

In your repository, in text files next to the code: requirements, documentation for each area of the system, plans, tests and the record of decisions. It goes through review like any change. If you stop using Clovis, it all stays there and serves the next developer.

Does it work on an old system with no documentation?

That is the most common case. In one of the projects the code was stored inside the database, with no repository to open. Clovis investigated, documented what the system did and brought to a human decision everything it could not state with certainty.

See the product

See Clovis running on your own code.

An engineer from our team runs Clovis with you, live, on one of your projects. You see the first questions reaching the people who decide. No slides.

The next step

Thirty minutes with the people who build it. You pick the time.

You have already seen what Discovery produces. From here on it is logistics: the calendar is public, the slot is yours, and an engineer sits on the other side.

  • Bring the repository, or just the problem. Either one works.
  • On the other side there is an engineer, not a sales script.
  • If it does not make sense for you, we say so on the spot.
CMMI DEV/3ISO/IEC 27001ISO/IEC 27701

Pick a time

Thirty minutes on our engineering team’s calendar. You get the invite with the call link right away.

  • 30 minutes. Straight to the point, no slide deck.
  • Your agenda. Legacy, architecture, AI governance, whatever is blocking you.
  • With the builders. Whoever joins the call is whoever signs the gate on your project.

Public calendar · no form

CMMI DEV/3ISO/IEC 27001ISO/IEC 27701