How does engagement work?

The model is assessed according to the project. First we understand the problem and map the complexity; from there we define scope, deliverables and deadlines, and only then do we discuss the engagement format — which can be a defined project or a technology partnership, when the idea is promising enough for us to share the risk. To size anything we need to know what goes in and out of the process you want to automate, and that is what the free fifteen-minute call is for.

How fast do you ship?

We work in weeks, not quarters. The first working deliverable usually ships within the first two weeks, because we use mature tools — n8n, LangChain, Next.js — instead of rebuilding everything from scratch. Larger projects are sliced into short, verifiable deliveries so you see something running well before the full scope is done.

Do you use n8n or LangChain? Which one is better?

Both, and the choice depends on the problem. n8n is better when the challenge is integrating systems and orchestrating a flow with predictable steps — every node is visual and auditable. LangChain comes in when language reasoning is required: agents that decide which tool to call, RAG systems answering from a knowledge base, chatbots wired into business rules. In practice most of our production systems combine the two.

Do I own the code and the infrastructure?

Yes. Code, infrastructure and credentials are yours from start to finish. We hand over with documentation and a proper handoff, so your team can operate and evolve the system without depending on us. We don't build vendor lock-in.

Will the AI make decisions on its own in my process?

Only if you want it to — and usually we advise against it. Our default pattern is that the model reads, extracts and converses, while business decisions stay in explicit, versioned, testable rules. In the credit pre-analysis engine we built, for instance, AI reads documents and images, but no credit conclusion is generated by a model. A system that decides on its own without leaving a trace does not reach production.

Do you work with clients outside Brazil?

Yes. We are based in Goiás, Brazil, and work remotely with clients across Brazil and abroad, in Portuguese and English. The whole process — discovery, delivery, review and handoff — runs remotely, and that is how we already run the systems we keep in production today.

How does the free 15-minute consultation work?

You describe the process you want to automate and you leave with a technical path: which tools to use, in what order, what is straightforward and where the risk sits. It is not a sales meeting: we don't present a commercial proposal in that call. If it makes sense to work together afterwards, then we talk about scope.

Published onSeptember 09, 20268 min read

How a credit analysis went from a full business day to minutes

The bottleneck was never the analysis. It was opening seven sources, taking screenshots and pasting them into a report. Here is the design that fixed it without handing the decision to a model.

Architecture
Automation
Applied AI
Credit

Credit analysis for a new customer took a full business day at a telecom carrier. When we timed where that day actually went, the answer was uncomfortable: almost all of it was collection. Opening seven different sources, checking registries, taking screenshots, pasting into a report, repeating. The analysis itself — reading the set and forming a judgement — took minutes.

The bottleneck wasn't judgement. It was moving information around. And moving information around is exactly what machines do better than people.

The temptation we avoided

The obvious 2026 move would be to throw the documents at a language model and ask for an opinion. It would work in a demo and be unsustainable in production, for three reasons that have nothing to do with model quality:

A credit decision has to be defended. When a customer challenges a rejection, someone must point to the rule that was applied. "The model thought so" is not an answer you give a regulator.
Models are not reproducible at the margin. Two runs over the same input can diverge, and in a risk process that is a defect, not a feature.
Reprocessing would be expensive. Changing a criterion would mean running everything again, including paid bureau queries.

Four stages, four artifacts

The design we settled on splits the process into four independent stages. Each receives a finished artifact, does one thing, and hands over another:

document + 7 sources
        ↓
  [1 · DATA]       ──►  dossier.json     what exists
        ↓
  [2 · RULES]      ──►  evaluations[]    what each rule said
        ↓
  [3 · DIAGNOSIS]  ──►  diagnosis.json   what it means
        ↓
  [4 · DOCUMENT]   ──►  report.pdf       how it reads

The separation looks bureaucratic until the first time someone asks to change a criterion. Because stage 2 reads an already-assembled dossier, you can change a rule and reprocess the whole analysis without touching stage 1 — meaning without paying again for bureau queries. In a process where every query costs money, that stops being architectural elegance and becomes direct savings.

Where AI comes in — and where it stops

AI operates exclusively in stage 1, and only to read. It extracts data from documents the analyst uploads, interprets screenshots of systems with no API, and helps identify which of the companies returned by a search is the target company — choosing among candidates, in a closed field, never inventing a new name.

After stage 1, no model call happens. The rules are code. The diagnosis is code. The report is a template. No sentence in the final document is model-generated.

In a process that has to be defended, AI pays off more as a reader than as a judge.

The rules that do not negotiate

Some decisions were written as system invariants, not preferences. These three prevented the most trouble:

Missing data is never a green light

When a source doesn't respond, the result of that check is indeterminate — and indeterminate is never converted into "no alert triggered". It sounds obvious written down, and it is exactly the most common silent bug in this kind of system: absence of an alert being read as absence of risk.

A failing collector becomes a gap, not an error

Seven external sources mean seven points of instability. If any one of them could take down the whole analysis, the system would be useless in practice. An unavailable source is recorded as missing information, the process continues, and the report explicitly shows what could not be verified.

Cache before any paid call

Bureau queries are billed per request. The system checks the cache before spending, and the stage separation guarantees that reprocessing after a rule change triggers no new collection.

What the analyst sees

From the user's side the change is simple: they attach the same report template they already used and get a tracking number immediately. Minutes later, the complete PDF report lands in the team's inbox, with evidence and screenshots attached in the right places.

And there is one line the system does not cross: it does not conclude. It neither approves nor rejects. The score in the report is an attention signal, not a decision — the decision stays with a person, now with the material ready in front of them.

What carries over from this architecture

The pattern applies to any process that must be audited: tax, legal, compliance. Separate collection from evaluation, leave AI on the reading side — where it genuinely removes a bottleneck — and keep the conclusion in explicit rules a person can read, version and challenge.

The time saved came from removing manual labour, not from outsourcing judgement. Those are different things, and confusing them is what leaves AI projects stuck at the pilot stage.