ESCAEnglish

Menu
Request the diagnostic

(What we do)

02 Applications, integrations and model-based systems, written for your operations.

This part brings together three classes of software: the applications each role works with, the integrations that move data between your programs, and the systems that put a language model to work inside a process, with limits set in code. All three share the environment, the accounts and the activity log of the rest of the system.

Applications for every role

Each application starts from an explicit data model and from the permissions that already exist in your company, and keeps a record of who creates, modifies or approves each entry.

  1. 01 Internal web applications

    Dashboards, portals, in-house CRMs and team tools in the browser, with one account per person and role-based permissions. They read and write through the same integrations as the rest of the system.

  2. 02 Apps for iPhone and Android

    For work away from the office: photos and voice notes on site, in the warehouse or on a visit, and checking the status of an order or a project. They use the phone's camera, microphone and notifications, and send what they capture to the same system the office uses.

  3. 03 Desktop programs for Mac and Windows

    For large local files, network folders or interaction with programs installed on the workstation, such as modelling, calculation or quoting software. They run on the computer and synchronise with the company's services.

  4. 04 Screens in front of legacy software

    The legacy program remains the system of record. The new screen validates each piece of data before writing it to that program, through the same route its integrations use, and each operation is recorded in full or not at all. A new project, customer or order is entered once and the screen distributes it among the programs that use it.

Integrations between programs

We choose the connection route for stability: first the vendor's documented interface, then file exchange and, as a last resort, reading its database directly, which demands more maintenance. Everything that comes in is stored raw before it is processed, so any piece of data can be reprocessed and audited.

Via API and webhooks

Connectors built on REST APIs, with webhooks when the program notifies its events and periodic polling when it does not. Every call respects the provider's rate limits, is retried with increasing back-off and is idempotent: a retry never duplicates an order or an invoice.

Via files

When there is no API, the exchange uses the formats the program already reads and writes: IFC from the BIM model, BC3 for the quoting software, DWG for drawings, and CSV, Excel or PDF for everything else. Each file is validated against its structure before it is imported.

MCP servers

An MCP server wraps a legacy system and exposes to a model a closed set of operations with typed parameters, most of them read-only. That way a model can query an ERP or a technical program without access to its database.

Testing each connector

A connector is signed off when the source program can be cut off in the middle of an operation without a single record being lost or duplicated. Each message is validated against the expected schema: if a provider changes a field, the message is stopped with its error instead of being half-written. The mappings between programs, such as customer and item codes, units or VAT rates, live in a table that can be reviewed.

Systems built on a specific model

Models differ in context window, reliability when calling tools, the number of tokens they generate for the same task and performance in each language. That is why each system has its own W.A.T. (Workflows, Agents, Tools) and its own process chains, tuned to the model and to the pinned version it runs on.

  1. 01 The workflow, designed for the model

    The workflow is the fixed sequence of the process. We split it into steps of the size that model handles reliably, each with its own instructions and schema, and we save the state of every stage: if something fails, the process resumes where it stopped. Whatever deterministic code can resolve does not go through the model.

  2. 02 Judgement, only where it is needed

    Agents are roles with a defined goal, tools and limits, and they only step in at the stages of the workflow that call for judgement: one drafts, another checks the result against rules, another prepares the action for a person to approve.

  3. 03 Precise tools

    Each tool does one thing only, with typed parameters, an unambiguous description and errors the model knows how to interpret. The model only proposes the call; execution, permissions and logging belong to our layer. Irreversible operations are kept out of the toolbox: they are carried out by a person, or by deterministic code after a recorded approval.

  4. 04 In the cloud or on your server

    With a cloud model, currently from the Mistral or Claude families, a step can handle more context and more tools. An open model installed on your server, such as Granite, ALIA/Salamandra or EuroLLM, receives shorter steps, fewer tools and stricter schemas, and no data leaves the company. We serve it with vLLM or SGLang in production, which reuse the cache across requests, and with Ollama for prototypes. The model for each task is reviewed every month.

The architecture of the whole system and the model layer

Efficiency and cost control

Each system is designed to spend as little as possible per useful result, with its limits written in code, where they do not depend on the model obeying an instruction.

  • Cost per completed task: we measure the cost of each order recorded or reply sent, not the price per token: a cheap model that generates more output tokens can end up costing more.
  • Stable prefix: instructions, schemas and tool definitions always go first and unchanged, to take advantage of the prefix cache of the provider or of your own server; whatever varies goes at the end.
  • Deterministic trimming: before summarising with a model, the context is trimmed by rules, discarding duplicates, old turns and fields the task does not use.
  • Hard caps: a maximum number of steps and a maximum spend per task and per key, enforced in code and logged.
  • Escalation by step: each step uses the cheapest model that resolves it reliably, tested on real cases, and only the cases that require it move up to a larger model.
  • Structured outputs: every response is an object validated against JSON Schema, with its confidence level and a flag saying whether it should go to a person. Anything that fails validation is logged as an error, with no silent retries.

Results and how they are measured

  • Less re-keying: the number of times the same data is typed into two programs, counted with the diagnostic's baseline method.
  • Time per task: before and after, for each task the software acts on, with the same method.
  • Cost and steps per completed task: in model-based systems, compared after every workflow adjustment or version change.
  • Entries stopped by validation: how much data each check holds back before it reaches a program, and for what reason.

Shall we bring your company up to date?

We start with a 30-minute call to understand your case and explain what the diagnostic consists of and what it costs.

Request the diagnostic