An AI agent is a system built on a language model that carries out a task on its own: it understands an instruction in natural language, plans the steps, uses company data and tools, and hands back a finished result. In companies it replaces not people but the repetitive, tedious part of their work: gathering information, preparing a document, handling an inquiry.
This article is a comparison, not a how-to. I show what AI agents do in Polish companies today, how three approaches to building them differ, what each one costs, and when an in-house team is enough and when it is not. I write from an implementation perspective: WeAreFuture is a Polish AI advisory and implementation firm based in Warsaw. The text is for people who decide on the budget, not for developers.
Want to test this on your own process? We launch an agent PoC in 2 weeks. See how we work on AI implementations.
What an AI agent is: a business definition
The simplest way to tell three terms apart is by what each thing can do without a human. A chatbot answers a question. Automation runs a rigid “if X, then Y” script. An AI agent receives a goal, sets the steps itself, reaches for data and tools, assesses the result, and can handle a situation nobody described in advance with a rule. We broke the distinction down in a separate piece on how an AI agent differs from automation.
This is also called “agentic AI”. It is not a separate technology, just a name for the same property: the system does not wait for the next instruction but carries the task through to the end and reaches for the tools it needs. The two terms are used interchangeably.
For the person deciding on the budget this has one practical consequence. An agent costs more than automation, to build and to maintain, so it pays off only where the task actually requires interpretation and decisions. If a process can be written down as a fixed script with no exceptions, an agent is an overpriced solution to a simple problem.
Let me defuse two myths right away, because they cost companies the most money. The first: “an agent is a better chatbot”. It is not, because a chatbot talks and an agent acts, and that action has to be designed, integrated and maintained. The second: “it is AI, so it will learn on its own”. An agent does not learn on its own in production. Its quality comes from the data it sees, the tools it has and how its work loop was designed.
The scale of the phenomenon in Poland is smaller than the headlines suggest. About 23% of companies actively use AI, and a large share of them do it in fragments, without a coherent architecture and without an owner of the topic (PARP, the Polish Agency for Enterprise Development, and Jagiellonian University, 2026). A well-implemented agent is still an advantage, not a market standard.
What AI agents do in companies today
Instead of a catalog of possibilities, here are the three uses we implement most often. Each solves a different type of problem and requires a different level of integration.
An agent that prepares sales meetings
Before a conversation, a salesperson needs the same set of information: what has happened with the client so far, what they bought, what open topics they have, what is going on in their company and industry. Gathering this from the CRM, the inbox, meeting notes and the web takes anywhere from a dozen minutes to an hour, and under time pressure it simply does not get done.
A meeting preparation agent does the same thing the same way every time: it pulls from the CRM and the contact history, adds external context, and assembles a note with a proposed agenda and questions. The gain is not saving an hour but that the salesperson walks into every meeting prepared, not only the most important ones. This is usually the simplest start, because the agent reads data and changes nothing in the systems.
An agent that handles requests for quotation (RFQ)
This is the use with the highest value in manufacturing and distribution companies, where quoting is the bottleneck of sales. The request arrives by email, in any format, often as a description of a need rather than a list of item numbers. Someone has to interpret it, select products and configuration, check availability and price, and prepare the document.
At a Polish manufacturing company, an agent integrated with the ERP, CRM, knowledge base and product data runs this whole process. The handling time of a single request fell from several days to around one day for repeatable, high-volume requests, at a volume of about 2,000 requests a month. The repeatable part of the work stopped requiring a human, and the sales team deals with what actually requires a decision.
It is also the hardest of the three cases, because the agent has to talk to the company’s systems and use current product data. The value is created here in integrations and data quality, not in the model itself.
We write separately about what decides the quality of an AI agent: the harness or the model.
An internal knowledge agent
The third type answers employees’ questions based on company documentation: procedures, specifications, contracts, product materials. It solves a problem that in most organizations is called “ask Kate, she knows”. The knowledge sits in a few heads and a few hundred files, and experienced employees are the bottleneck for the rest of the team.
A knowledge agent shortens onboarding and takes load off experts, but it has one boundary condition: it is exactly as good as the documentation it gets. If three versions of the same procedure circulate in the company, the agent will replicate that mess with full confidence. That is why with this type of implementation we start by organizing the sources and access rules, as we describe in more detail in the piece on shared context and skills.
What such an AI assistant on company documents gives employees, what it will not do, and how long its implementation takes, we laid out in a separate guide.
These three cases differ in difficulty, but one thing connects them: the agent does not replace the whole job here, it takes the repeatable part off it. The salesperson still leads the conversation, the expert still settles the hard cases, and quoting still has an owner on the company’s side. This distinction has to be made at the start of the project, because implementations sold as “the agent will replace the department” end in team resistance and quiet boycott, while implementations described as “the agent prepares the material, you decide” get adoption from the first week.
Comparing approaches to building agents
This is the most important decision in the whole project and also the one most often made by accident. There are three routes, and they differ less in the quality of the result than in cost, time and who has to maintain it afterwards.
The three routes to an AI agent differ in time, cost and who maintains it afterwards.
Approach | Time to first version | Cost (order of magnitude) | Skills needed | When to choose |
|---|---|---|---|---|
No-code (n8n, Make, Copilot Studio) | days to 2-3 weeks | lowest | process analyst, integration basics | simple, repeatable flow; first PoC; a single department |
Vendor platforms (Claude, OpenAI, Microsoft) | 2-6 weeks | medium | engineer plus business owner | work on company knowledge and documents, standard integrations |
Custom development | 6 weeks and up | highest | engineering team and maintenance | critical process, deep ERP and CRM integrations, security requirements |
No-code. Tools such as n8n, Make or Microsoft Copilot Studio let you assemble a working agent without writing code, at a pace measured in days. It is the best way to test a hypothesis and show the organization a result before anyone approves a larger budget. Limits appear at scale: complex logic, versioning, testing and audit get harder, and with several dozen flows maintenance starts to get expensive. A common mistake is that a successful PoC stays in production for years because “it works, after all”.
Vendor platforms. Solutions from model providers come with a ready layer of security, access control and document handling, plus a predictable licensing model. This is usually the best ratio of result to effort for knowledge agents and for tasks where the quality of work with text matters. The price of convenience is less freedom of configuration and dependence on a single vendor, so make sure up front that the data and the process logic can be moved.
Custom development. A custom solution makes sense where the process is critical to the business, the integrations reach deep into the ERP or CRM, and security requirements allow no compromise. It gives full control and handles scale best, but it is the most expensive to build and, more importantly, to maintain. The RFQ case described above belongs to this category, because without integration with the company’s systems that result could not have been achieved.
A separate criterion, which in regulated companies can be decisive, is where the data flows. Data security concerns are the most frequently cited barrier to AI adoption in Polish companies, named by 65% of them (PARP and Jagiellonian University, 2026). In no-code tools data travels through the platform vendor’s service and through every connected component, so with sensitive data you have to check exactly what is on the way. Vendor platforms offer, in their business plans, administrative control, access management and settings that exclude the use of data for model training, which personal accounts do not have. A custom solution lets you keep everything in the company’s infrastructure, including an on-premise environment, and that is usually the only route when data cannot leave the organization. This decision is made before the build, not after the first audit.
Most organizations do not choose one route forever. They start with no-code to validate the idea and move the flows that proved valuable to a sturdier architecture. That is a sensible order, on one condition: decide up front how you will know that a PoC deserves a rewrite.
Build it yourself or with a partner
The honest answer is: it depends on whether the agent is a one-off improvement or an element of a process that money depends on.
An in-house team is enough when the process is internal and non-critical, the data sits in one or two systems with an available API, you have someone who knows no-code tools and has the time, and the cost of a possible mistake is low. In that setup, building in-house is cheaper, faster and builds skills that stay in the company. If only knowledge is missing, AI training for companies is sometimes a more sensible investment than an implementation project.
A partner makes sense when the agent touches a revenue process or customer service, requires integration with an ERP, CRM or document systems, is subject to compliance requirements, or when the team has the skills but no free hands. A second, less often mentioned reason is speed: an external team that has done this a dozen times recognizes faster what will not work and does not pay for learning on your project.
There is also a third option, the most common and the healthiest: the first implementation with a partner, but on the premise that your team works on it from the start and takes over maintenance. Then you buy speed and learn from a working example, instead of being left with a solution nobody inside understands.
An advisor who answers every question with “build it, with us” is not an advisor. Part of our work is saying plainly that in a given process an agent will not pay back and AI automation in the company or simply tidying up the process is enough.
How much an AI agent costs
The price of an agent depends on three things, and only one of them is technology: the number of integrations, the state of the data, and how critical the process is. The cost of the model itself is usually the smallest item in the budget today. AI budgets are growing: 90% of companies increased their AI investment over the past year, and 96% plan further growth (Deloitte, 2026). That does not remove the need to calculate whether a specific agent will pay back.
Cost ranges for an AI agent in three layers. WeAreFuture estimate based on 2026 implementations.
Count in three layers.
PoC. The version that has to answer the question “will this work at all on our data”. With the no-code approach it is a matter of days and the lowest entry threshold; with an approach that requires integration, several weeks of team work. Roughly PLN 10-30k, depending on how many systems have to be connected and what state the data is in (WeAreFuture estimate).
Production. The version that works every day, has an owner, error handling and monitoring. As we wrote about AI implementations from chaos to order, such an implementation is roughly PLN 35-100k and more, and with many integrations with an ERP, CRM or data warehouse the cost grows several times over (WeAreFuture estimate).
Maintenance. The item most often forgotten at the decision stage, and one that can exceed the cost of building over a two-year horizon. Systems change, data changes, processes change, and the agent has to keep up. For a production implementation maintenance is usually from a few thousand PLN per month (WeAreFuture estimate), and it covers: monitoring and error handling, updating integrations after changes in source systems, refreshing the data and context the agent uses, model and infrastructure costs, and small changes in logic requested by the business.
The largest part of cost and time is usually generated by the data layer, not the agent itself. If product data is incomplete or procedures live in several versions, the project first pays to organize them. That is uncomfortable news at the quote stage and the best investment over the following implementations, because every next agent benefits from an organized data layer.
Four things drive the price up above all: the number of systems the agent has to talk to, the lack of an API on the side of those systems, scattered or incomplete data, and a high cost of error that forces additional controls and a human in the loop. It is lowered by: a narrow scope of the first version, one well-described process, ready integrations and organized documentation. That is why the same task can cost several times more or less in two companies, and the difference comes not from technology but from the organization’s state of preparation. If you are planning a system migration, for example an ERP change within a dozen or so months, factor it into the architecture from the start instead of building integrations that will soon have to be rewritten.
A simple profitability test before you calculate anything in more detail: multiply the number of times the process runs per month by the time of one run. If the result does not impress you on paper, it will not impress you in the budget either.
Where to start: a first agent in 2 weeks
Two weeks is enough to have a working proof on your own data, as long as the scope is narrow and decisions are made quickly. Below is the order we follow.
The order we follow with a first agent. Without a decision point, a pilot lasts half a year.
Choose one process, not an area. Not “sales”, but “preparing a quote for a standard request”. The narrower the scope, the greater the chance of a result in two weeks.
Check the data before you build anything. Does the information the agent needs exist in a usable form, and can you reach it without a three-month integration project. This is the most common reason a PoC gets delayed.
Set the metric before the start. Handling time, number of human touches, share of cases handled without correction. Measured the same way before and after, otherwise the conversation about return turns into a conversation about impressions.
Assign a business owner. A person who knows the process and has the mandate to decide what the agent does in disputed cases. A deployment without an owner is a future abandoned pilot.
Build the simplest version that solves the problem. The main path first, exceptions later. An agent that handles 70% of cases and honestly hands the rest to a human is worth more than one that was meant to handle everything and never reached production.
Plan the decision point. At the end of two weeks you answer one question: scale, fix or close. The lack of such a point is the easiest road to a pilot that lasts half a year and ends in nothing.
You also need to know what not to do at the start. Do not start with a process that is both critical and poorly described, because the first failure shuts the topic down for a year. Do not build an agent “for everything”, because the scope will drift by the third week. Do not start with a process that has no owner, hoping one turns up along the way. And do not buy licenses for the whole company before one team shows that the solution works for them in production, because the return is decided by actual use, not by the number of purchased seats.
If a first agent is to be followed by a second and a third, take care of a shared foundation right away: the data layer, access rules and the way you measure the effect. That is exactly what the AI Engine is: a shared company context used by people and agents, built in stages, process by process, so that every next implementation does not start from zero.
Before you start, it is worth aligning the language in the team. We described the free course “Agent vs Assistant: Fundamentals” and the workshop “AI Agents in Practice” in our overview of AI courses and workshops from the Polish Development Fund (PFR).
Want to test an agent on your own process? We launch a PoC in 2 weeks: we choose the process, check the data, build a working version and show the result on your numbers. Book a call about implementation.
Frequently asked questions (FAQ)
How much does implementing an AI agent cost?
It depends on the approach and the number of integrations. A simple agent built in no-code tools has the lowest entry threshold and is built in days. A PoC is roughly PLN 10-30k, and a production implementation integrated with company systems is PLN 35-100k and more, and several times more with many integrations with an ERP, CRM or data warehouse. You need to add maintenance to the budget, from a few thousand PLN per month, because systems and processes change. The largest part of the cost is usually the data layer, not the model itself.
How does an AI agent differ from a chatbot?
A chatbot answers questions, an agent performs tasks. An agent receives a goal, plans the steps, uses company data and tools, checks the result and handles exceptions nobody described in advance. Most helpful “company chatbots” are in fact agents working on the organization’s knowledge, not simple answer windows.
How do you create an AI agent in a company?
Start with one narrow process, check the state of the data, set a metric and a business owner, and only then choose the tool. Build the first version in no-code so that you see a result on your own data in two weeks, and only after the decision point move it to a sturdier architecture. The order matters: choosing technology before choosing the process is the most common reason for abandoned pilots.
Which processes are suitable to start with?
The best are those that are repeatable, high-volume, require interpreting text and have a clear owner on the business side. Handling requests for quotation, preparing sales meetings and answering questions from company documentation work well. We advise against starting with a process that changes every month or has no organized data.
How long does implementing an AI agent take?
A working proof on your own data takes about two weeks if the scope is narrow. A production implementation with integrations usually takes from a few weeks to a few months, and the time depends above all on the state of the data and the number of systems the agent has to talk to, not on the model itself.
Does an agent need access to our data?
Yes, and it is access to data that decides its usefulness. The scope of access, however, is set before implementation: which systems, which documents, what confidentiality levels and who approves it. Sensitive data can be processed in a private or on-premise environment so that it does not leave the company’s infrastructure. We set the architecture and access rules before the first line of configuration, not after the fact.
Sources
PARP and Jagiellonian University (2026), Artificial Intelligence in Companies: Adoption Readiness, Competencies and Needs - about 23% of companies actively use AI, data security as a barrier for 65% of companies.
Deloitte (2026), Return on AI Investment: The Polish Perspective - 90% of companies increased AI investment, 96% plan further growth.
WeAreFuture implementation data: RFQ handling time cut from several days to around one day for repeatable, high-volume requests, at a manufacturing company (WeAreFuture, 2026).
