The assistant works in 1C through permitted operations — every action is named and logged

An AI agent for 1C: permitted operations instead of database access

To be useful, AI needs hands: find a document, check a balance, gather the data for a reply. Direct database access is dangerous and does not get approved. We give the agent access over the open MCP protocol: permitted operations only, through a single gateway to 1C, with every action logged. A data map tells the agent how the database is built, and the 1C configurations are under version control.

01Who it is for
  • Companies on 1C that want an AI assistant in their accounting processes
  • IT teams that will not approve direct database access for external services
  • Accounting and warehouse teams that still type in primary documents by hand
02What it replaces
  • Direct database access to 1C for an assistant or a contractor
  • Home-grown scripts nobody dares to touch
  • Typing in primary documents by hand
AI agent for 1C
03Components

What is included

Assistant access to systems

1C, CRM and external APIs over an open protocol
in production

The layer through which assistants and agents work with accounting systems, CRM and external APIs over the open MCP protocol: permitted operations, not raw database access. The assistant files expense reports and per diems this way, from receipts to a payment statement after approval.

The job

Give assistants hands — while keeping every action limited, named and logged.

What hurt

  • Automation stalls because the assistant has no access to the systems
  • Direct database access is dangerous and never gets approved

What you get

  • The assistant performs operations itself, within a permitted set
  • Every action is named and logged, so an incident can be investigated
  • A new integration is connected in days, not in a quarter

What your client gets

  • Routine requests are handled without waiting for a free specialist
last change: 30 Sep 2026

1C under version control

Configurations as source code
in production

Accounting-system configurations and their exchange logic live in repositories: every change has an author, a history and a way back. Each night the exchange logic in production is checked against the repository, so a change made around it shows up by morning.

The job

Make 1C changes reversible and reviewable, the way ordinary software development works.

last change: 30 Sep 2026

Exchange bus

One envelope, delivery guarantees, tracing
in production

The central exchange bus between systems: one message envelope, versioned contracts, idempotency, retries with backoff, a dead-letter queue and end-to-end tracing. No new infrastructure — it runs on the database you already have.

The job

Make system-to-system exchanges predictable: no lost messages, no duplicates and always visible in flight.

What hurt

  • Every integration is written differently, each with its own failure modes
  • A lost message is discovered by a complaint, not by monitoring
  • A system cannot be replaced because dozens of direct links hang off it

What you get

  • Delivery is guaranteed and a retry does not create a duplicate
  • A message's whole path is visible; investigation takes minutes
  • A system can be replaced whole without touching its counterparties

What your client gets

  • Data does not drift between systems and an order is not lost at a seam
last change: 30 Sep 2026

Exchange contracts

Message definitions kept apart from code
in production

Versioned definitions of the messages systems exchange. A contract describes the message, not the service code, so a system can be replaced without rewriting everyone who talks to it.

last change: 30 Sep 2026

Data map

A corporate schema for people and agents
pilot

Builds a map of corporate database structure: tables, domains, relations and lineage. Useful both to a person investigating and to an agent working with the data.

last change: 21 Sep 2026

1C gateway

One door instead of a dozen integrations
in development

One access point to the accounting core: external services reach 1C through a gateway by contract instead of connecting to the database directly.

last change: 30 Sep 2026
04Implementation

How it works for you

Describe the operations

We list what the agent may do in 1C: find, read, prepare a document. Everything else stays closed.

Connect through a gateway

The agent reaches 1C through a single access point under a contract, not directly in the database.

Give the agent a data map

The agent sees the database schema — tables, relations, data lineage — instead of guessing where things are.

Log every action

What the agent did and for whom is visible, so an incident can be reviewed.

05Comparison

Three ways to solve this

We are not the only option, and we show plainly where we lose.

Build it yourselfOff-the-shelf vendorBIOCARD Tech
Time to first resultQuarters: hiring, learning the domain, architecture from scratchWeeks to install — then months bending processes to fit the boxA demo immediately, a pilot in weeks: the product already exists
Domain contextYou will have to teach the team what a batch and a temperature mode areA generic product with no notion of a shipment or a cold chainWe work in it daily — the context is included
Who carries the riskYou do: for the timeline and for the solution turning out wrongYou do: changes outside the vendor roadmap usually never happenWe do: the product runs in our own company and we use it ourselves
Changes for youAnything is possible — if the team stays and is not pulled elsewhereOn the vendor's roadmap and prioritiesDays rather than quarters: our own delivery pipeline
Where we loseFull control over the code and priorities stays with youA large partner ecosystem, training and certificationWe are a small team and we do not take every job
06Cost

Price on request

There is no price list, and that is not a trick: almost every product needs configuration for your processes and integrations, so the same system costs differently at two companies. We quote after the demo, when the scope is visible — not before it.

01

What you get

A working product rather than from-scratch development. The core already exists and runs in our own company, so you pay for the rollout and the fit-out, not for inventing the solution.

02

What the quote is made of

The amount of fit-out for your processes, the number and complexity of integrations, and the requirements around data and timing. All of it becomes visible after a demo on your own data.

03

When we name a figure

After the demo and a short review of your case. The quote is fixed — not time-and-materials.

Where the work stops

The agent gets no direct database access and never goes beyond the list of permitted operations. Posting documents and payments stay with a person by default. Recognition of primary documents is planned.

07FAQ

Questions about this solution

What is MCP?

An open protocol through which an AI assistant receives a list of permitted operations rather than the database. Every operation is named, limited and logged.

Will it fit our 1C configuration?

The operations and the gateway are described for your configuration. We run several 1C configurations ourselves — for transport, warehouse and accounting — so working with different configurations is routine for us.

Can the agent post a document or a payment?

Only if that operation is on the permitted list. By default we leave posting and payments with a person.

How long does connecting take?

A new MCP integration connects in days, not a quarter. Agreeing the access rights usually takes the longest.

In practice: eight tasks an AI agent already does in logistics →

08More solutions

Related solutions

See it on your data

Forty minutes, a working product, no slides. Then a pilot in your environment.

All solutions →

Discuss your case