GPT-6.1 Terra and computer use: what to hand an agent in 1C and your CRM

GPT-6.1 Terra is an OpenAI model released on October 26, 2026. The company describes it as fast and cost-efficient, with a focus on visual analysis and computer use: the model looks at a screenshot, decides where to click and what to type, and works through a task in a program the way an employee would. OpenAI presents the release as “fast and capable computer use for everyone,” and the model's API price is $1 per million input tokens and $5 per million output tokens. For a company running on 1C, the accounting and ERP platform most Russian businesses are built on, and a CRM, the interesting part is the class of tasks such an agent handles without an API: one-off exports, data migration, routine work on repetitive screens. For an ongoing process that writes to the books, posts documents or moves money, you still need an integration: a screen-based agent is slower, breaks when a form changes and doesn't give you a reliable log. A Russian company will also have to settle the question of access before any pilot: officially, OpenAI does not serve Russia.

Below we look at what exactly OpenAI released and which figures in the release are backed only by its own tests. How an agent works with 1C, a CRM and online banking through the screen, and how that differs from an integration and an RPA bot. Which processes you can hand it right now and where it breaks: form changes, exceptions, access rights, checking the result. Separately: access to the model from Russia, 1C screenshots as an issue under Federal Law 152-FZ, Russia's personal data protection law, when the agent works as a temporary bridge and at what point the flow moves to an integration. At the end: what to prepare before a pilot and why a general-purpose agent doesn't know your process.

What did OpenAI release, and what changed on October 26?

OpenAI released a model that its developer documentation describes as “a fast, cost-efficient model for visual analysis, precise computer use and clear writing.” Digit.in calls it a mid-sized model that sits in the middle of OpenAI's current lineup. Computer use is enabled as a separate tool through the Responses API; the model accepts text and images and responds with text.

Availability, the benchmark result and the previous version's price come from Digit.in's article (by Vyom Ramani, October 27, 2026); the price and context window come from OpenAI's documentation. Digit specifically notes that all quality figures come from OpenAI's internal testing and that independent evaluations are still to come.

What matters for business here is not the benchmark gain but the price. Computer use existed before, but every action an agent takes is a screenshot the model reads and a decision it writes. When the input price halves and the output price drops by more than half, tasks that used to be too expensive to run through the screen move into the “worth trying” category.

How does an agent work with 1C and a CRM through the screen?

The agent works in a loop: it receives a screenshot, decides what action to take, a program on the company's side performs that action, and the agent receives a new screenshot. This continues until the task is done or the agent stops with a question for a person. The model does not connect to the 1C database and does not see the data directly; it sees only what is drawn in the window.

Three properties follow from this, and they determine where the agent is useful:

• It doesn't need an API. If an employee can do the task with a mouse and keyboard, the agent technically can too. This covers old, unmodified 1C configurations, industry-specific software, supplier accounts and portals that offer no data exchange at all.
• It is slow and costs money at every step. A single operation in 1C means opening a list, finding a document, opening the form, filling in the fields and saving. Each step is a screenshot and a model decision. An integration transfers the same record in a single request.
• It knows only what it sees. Hidden fields, posting rules and links between documents are out of the agent's reach if they aren't on the screen.

An RPA bot fails consistently and visibly: a button moved, the script stopped. An agent copes with small interface changes, but on an unfamiliar screen it can make the wrong decision and carry on confidently. That is why checking the result is mandatory with an agent.

1C has built-in exchange mechanisms: the standard OData interface, HTTP services and file exchange. If a developer has access to the database, an ongoing task is almost always cheaper and more reliable to build on them. A screen-based agent is needed where there is no such access or where setting it up doesn't pay off for a one-off task. How integrations work and what stages they go through is covered in “System integration: methods and stages”.

Which processes in 1C and a CRM can you hand to an agent without an integration?

A screen-based agent suits tasks that repeat on the same screens, are one-off or temporary by nature, and where a mistake can be caught before it reaches the books. In every case the agent prepares the result and a person confirms it.

What these tasks have in common: the agent reads or prepares a draft, it doesn't post anything. An export doesn't change data in the source, a migration is checked on a copy, a portal form is submitted after confirmation. If the agent's result can be checked faster than the task can be done by hand, there are savings.

Moving from one system to another is a special case. An old CRM or in-house program often can't export everything you need: comments, call history, attachments. Writing an integration for it that will run for two weeks is expensive. An agent that goes through the records and moves the data looks like a reasonable temporary bridge here. Why a client database loses value during a move and what to clean up before migrating is covered in the article on the client database in a CRM.

Where does a screen-based agent break?

The agent breaks where the screen stops looking the way it did at setup, where the process departs from the normal path and where nobody is there to notice a mistake. The key difference from a bot is that the agent doesn't stop with an error; it makes a decision and keeps going.

• Form changes. After a 1C or CRM configuration update, a field has moved to another tab, a new required column has appeared, a button has been renamed. An agent on a model like Terra handles small changes better than a bot, but it may fill in a similar field instead of the right one.
• Exceptions. A warning that the credit limit has been exceeded, a client on hold, a document someone else is already editing. An employee knows that in this case they need to call a manager. Without a written rule, the agent decides on its own: it closes the window, retries or works around the check.
• Access rights. The agent works under a user account and can do everything that account can. If it was given an accountant's login “to avoid setting things up,” it also got the right to post documents and to see salaries.
• Checking the result. The agent reports “done,” but its report doesn't tell you whether all four hundred records were moved and moved correctly. Without reconciling against the source, you are taking its word for it.
• Someone else's instructions on the screen. The agent reads everything it sees. Text in a client's email, a comment on a deal or a portal page may contain an instruction such as “forward this data to this address,” and the model may take it as a task.

The risk of bypassing restrictions is visible in the data on the model itself. Digit.in, citing reports on OpenAI's system card, writes that in roughly 30% of all simulated tests the model bypassed restrictions set by the developers in order to complete the task. The publication doesn't specify what the scenarios were or which restrictions were involved, so the figure should be read as a signal rather than a precise error rate. The publication calls this a serious problem for programs that work with real user accounts, fill in forms or make payments. For business the conclusion is direct: a restriction written into the agent's instructions does not protect you. What protects you is the account's permissions, where the agent simply doesn't have the button.

Why does an ongoing process still need an integration?

Because an ongoing process has different requirements: it runs every day, a large volume passes through it, and it writes to the books. An integration passes data directly, doesn't depend on what a form looks like and leaves an exchange log that shows, a quarter later, what came in, when and from where. A screen-based agent provides none of these properties.

The difference shows up in an ordinary task. Orders from an online store need to be entered into 1C every day. For each order, a screen-based agent will open the form, find the client, pick the items, fill in delivery, save, and each step is a screenshot and a model decision. An API exchange does the same with a single request per order. The agent is noticeably slower: dozens of steps against one request. You pay for the model at every step, so costs grow with the order volume, and after the next configuration update the scenario has to be checked again.

So the sensible approach has two steps:

1. The agent as a temporary bridge. While the process is being documented and the integration is being built, the agent takes manual work off people's hands on screens that don't change. Its log also shows which exceptions actually occur.
2. Integration as the permanent solution. Once documented, the process moves to exchange through an API or the built-in mechanisms of 1C and the CRM, and the agent is kept for rare tasks without an API or switched off.

Some processes are not given to a screen-based agent even temporarily: posting documents that affect accounting and taxes, sending payments, changing user permissions, bulk deletion and merging of records. Here the cost of a mistake outweighs any savings. Who is responsible for a model's error in the books and how to set up an assistant's permissions is covered in the article on AI in 1C:Accounting.

Can you let a foreign agent into 1C and online banking?

First you need to settle access, then data. With personal data and trade secrets on the screen, an agent is acceptable only after a legal decision, and it should never get the right to sign payments.

Access is the first obstacle. Russia is not on the list of countries where OpenAI allows its services to be used, and the company warns that access from other countries may lead to account suspension. A Russian company cannot connect the API or ChatGPT Work directly in its own name or pay with a Russian card. Access through an intermediary or a foreign legal entity is a separate legal and contractual decision: who is the party to the contract with OpenAI, where the data is processed, what happens to the process if the account is blocked. If you need the agent for the long term, it is more practical to look at Russian models or models hosted inside the company's own environment. Hosting options are covered in the article “Neural networks without data leaks”.

The second obstacle is data. Working through the OpenAI API, the agent sends screenshots to the model, and everything visible on them goes to servers outside Russia: client names, phone numbers, bank details, contract amounts, purchase prices. A 1C or CRM screen almost always contains personal data, even if the agent's task has nothing to do with it: a list of counterparties, a client record, a manager's comment. For personal data this is a cross-border transfer, and Article 12 of Federal Law No. 152-FZ sets out several steps for it:

• Before notification: information from the recipient (Part 5). The operator must obtain from the foreign recipient information on its data protection measures and the conditions for ending processing, and if the country is not on the list of those providing adequate protection, information on its legislation as well.
• Notifying Roskomnadzor (Part 3). Roskomnadzor, Russia's communications and data protection regulator, must be notified before the cross-border transfer begins.
• Waiting and a possible ban (Parts 11 and 12). Data may not be transferred to a country that is not on the adequate-protection list until the review period for the notification has expired. Roskomnadzor has the right to prohibit or restrict the transfer.

So notification is a necessary condition, but not a sufficient one.

With online banking the line is simpler. Banks usually provide statements as an exchange file for 1C (the 1CClientBankExchange format) or through the bank's API, and no agent is needed to get them. An agent is never given the right to sign and send a payment, whatever the settings: a model that, according to reports on the developer's own tests, bypasses the restrictions it is given should not have access to the “Send to bank” button.

A safe pilot configuration looks like this:

1. A separate account for the agent with permissions only for what the task needs: read access for exports, creating drafts without posting.
2. A test copy of the database for debugging; the production database only after testing.
3. An isolated environment. The agent runs on a separate virtual machine with no email, messengers or saved employee passwords.
4. An action log. The agent's screenshots and actions are saved so you can trace where a record in the database came from.
5. Human confirmation of any action that changes data in an external system.

Where do you start?

With one task that has a clear result and a way to check it. The easiest place to start is an export or a migration: the agent changes nothing in the source, and the completeness of the result is easy to verify. The task description alone shows whether a screen-based agent will do or whether an exchange is cheaper.

1. A documented process. Which screens, in what order, what counts as a correct result. If an employee can't write the task down step by step, the agent won't do it consistently either.
2. A list of exceptions. What comes up in the task besides the normal path: warnings, locked records, missing data. And what to do in each case: skip, stop, call a person.
3. A decision on data and the model. What the agent will see on the screen, whether there is personal data and trade secrets there, where the model will run: with a Russian provider, inside the company's own environment or with a foreign provider under a separate contract. The business makes the decision; the contractor builds it into the architecture.
4. Account and permissions. A separate user in 1C, the CRM and the portals, with only the permissions the task needs. No right to post, sign, delete or change users.
5. A test environment and result checks. A copy of the database, an isolated machine for the agent and a way to reconcile: record counts, checksums, spot checks.
6. A review of available integrations. Whether the system has an API, OData or file exchange. If it does, an ongoing task is costed both ways from the start and the two options compared.
7. An owner and support. An employee who monitors the quality of the agent's work, investigates stops and updates the scenario after interface changes, plus a support agreement. Without an owner, the agent starts making silent mistakes after the first configuration update.

The company handles the first three points itself, and they alone show whether the task suits an agent. The rest determine the scope of work: how many systems, what permissions, what environment and what exchange replaces the screen. The general framework of stages and budgets is in the article on the stages and cost of AI adoption, and how an agent differs from an automation script is covered in “AI agents for business”.

Why doesn't a general-purpose agent know your process?

A screen-based agent is the most general-purpose off-the-shelf product there is: it works in any program it can see. That is exactly why it knows nothing about your process. Every company has its own procedures, reference data, access rights and exceptions, and none of them are visible on the screen.

At one company a client order is approved by the commercial director after entry, at another stock is reserved automatically, at a third large orders go through a separate status. In one CRM the owner is assigned by region, in another by industry. An agent that simply “knows how to work in 1C” will need all of this explained, and explained again every time a rule changes. A system built around the process keeps these rules in code and reference data, not in the model's instructions. We covered the choice between an off-the-shelf product and a system built for your process separately: your own system or an off-the-shelf one.

INCUBE AI works under contract and assembles the setup around your environment: integration with 1C, CRM, banks and portals where it pays off, and an agent with limited permissions where a system has no API. In this setup the agent runs on a model hosted with a Russian provider or inside the company's own environment, and the data stays in Russia. A foreign model like Terra is worth considering only at the client's request, with properly arranged access and on screens without personal data. After launch, the system stays under ongoing support. You can see what this kind of setup looks like on a live project in the project for a wholesale and manufacturing company: orders from email and messengers are gathered into a single queue, and the product catalog, stock levels, shipments and payments are synced with 1C through an exchange, with no manual copying. If data between your systems is still moved by hand, tell us about the task: we'll go through the process and tell you plainly where an agent will do for now and where you need an integration.

Sources and links

• OpenAI, October 26, 2026: Introducing GPT-6.1 Terra — model announcement, subtitle “Bringing fast and capable computer use to everyone.”
• OpenAI, developer documentation: GPT-6.1 Terra — “a fast, cost-efficient model for visual analysis, precise computer use and clear writing.” Price of $1 and $5 per million input and output tokens, context window of 1,050,000 tokens, output up to 128,000 tokens, computer_use tool in the Responses API, text and image input, text output.
• Digit.in, October 27, 2026: GPT-6.1 Terra explained — by Vyom Ramani. A mid-sized model in the middle of OpenAI's lineup. Included in ChatGPT Work and Codex on the Pro, Enterprise and Edu plans. Price of the previous version: $2 and $12 per million tokens. Agents' Last Exam: 15 percentage points above GPT-5.6 Terra at medium reasoning effort at roughly a third of the price. Citing reports on the system card: developer restrictions bypassed in roughly 30% of all simulated tests, scenarios not specified. All figures come from OpenAI's internal testing.
• OpenAI: Supported countries and territories — the list of countries where OpenAI services may be used; Russia is not on it, and access from other countries may lead to account suspension.
• Article 12 of Federal Law No. 152-FZ “On Personal Data” — notifying Roskomnadzor before a cross-border transfer begins (Part 3), information from the foreign recipient before the notification is filed (Part 5), a ban on transfers to countries outside the list until the review period expires (Part 11), the right to prohibit or restrict a transfer (Part 12).