What an AI agent is, and what separates it from a chatbot
A chatbot answers a question, and then the case is over. An AI agent does a job. It often starts without any chat, from an incoming email or a new ticket, reads the case, pulls context out of your systems, runs several steps and leaves a result where your work actually happens: a draft order in the ERP, a classified ticket in the right queue, a prepared reply in the inbox.
Technically an agent has four parts. The language model supplies language understanding and judgement. The tools give it access to your systems, a CRM, a ticketing system, a price list. The memory holds what has already happened in the case at hand. The rules set out what it may do without asking. In production this runs as a loop: goal, next step, tool, check the result, continue or hand over. That is where it differs from classic automation. The goal is fixed in advance; the path to it is not.
Most of the "we need an agent" conversations we have end in a workflow with a single, tightly bounded agentic step. For most business processes that is the better design. Autonomy is a capability and a risk at once, and it is earned per action type, against measured error rates. The distinction in detail is in the glossary under AI agent and agentic workflow.
Which workflows suit a first agent
A good candidate has three properties: it happens often, it has a recognisable intake, and it produces a result someone can check. The value rarely appears where a whole role is meant to be replaced. It appears in the cases that come up many times a day and touch the same two or three systems every time.
- Support triage. Read every incoming request, classify it, draft a first answer from the knowledge base, route it to the right queue, escalate to a person when confidence is low. At Projektron the agent classifies 71% of tickets automatically and has cut median time to first response by 58%.
- Order entry. Orders arrive as PDFs, free-text emails or scans, every customer in their own format. The agent reads the order, matches line items against the article master, flags discrepancies and creates a draft order. A person confirms it.
- Supplier and customer email in procurement. Order confirmations, delay notices, price changes and complaints get classified, enriched with context from ERP and CRM, and passed on as a draft reply or an internal escalation.
- Quote preparation. Read the enquiry, pull master data and the price list, prepare a draft quote with its open questions for sales to check and send.
- CRM upkeep and follow-ups. Create contacts, log interactions, research new leads, chase what is due. At twigbit that is Chameleon.
- Content research and drafts. Research topics, gather sources, prepare drafts in the house voice for a person to approve. At twigbit that is Woodpecker.
- Reporting and anomalies. Watch agreed metrics, investigate material changes, present findings with sources and open questions. At twigbit that is Seagull.
The warning signs are unclear goals, irreversible decisions without approval, and cases too rare to fill an eval suite. An agent that decides about people, ranking applicants or assessing creditworthiness, is a high-risk system under the EU AI Act and not a first agent.
We bring four agents out of our own operation: Woodpecker for content, Chameleon for the CRM, Seagull for reporting and Lynx for SEO and accessibility. They run here daily, and their roles, evals and permission models are the starting point when your workflow resembles one of them.
Integrating into IT that has grown over years
An agent is software in your stack, not another platform with its own login. We build it onto the systems you have: CRMs like HubSpot, Salesforce or Pipedrive, your ERP, ticketing systems like Zendesk, Jira or Freshdesk, Microsoft 365 or Google Workspace, Slack or Teams. Where you already run Langdock, ChatGPT Enterprise or Copilot, we deliver the agent into those, through MCP servers and skills, so your people stay in the interface they know. How that works technically is under Model Context Protocol.
Three principles hold in every project. First, least privilege: the agent gets exactly the access its job requires, and identity and permissions live in your IAM, not with us. Second, documented data flows before the first live run: which source, which model, which region, which retention. Third, no lock-in: code, prompts, evals and configuration live in your repository. We work like any software vendor under a maintenance contract, and the contract settles the exit before the agent goes live.
For hosting there are three routes: model providers with an EU region and a processing agreement, European providers, or models on your own infrastructure where your data and the job call for it. The choice is made during the sprint, together with your IT and your data protection officer, and it is written into the documentation afterwards.
Data protection, GDPR and the EU AI Act
An agent that reads email and queries your CRM processes personal data all day. The questions that follow are well known, and we answer them in the design rather than afterwards. The legal basis under Art. 6 GDPR is documented, usually through a legitimate-interest assessment. Decisions with legal or similarly significant effect keep effective human review, as Art. 22 requires, and "effective" means something: whoever nods through 400 results a day is not reviewing. The model provider is engaged as a processor under Art. 28, with a contract, a sub-processor list and a clear answer to where inference runs. Where customer or employee data is processed systematically, a data protection impact assessment under Art. 35 comes before go-live. Retrieval stays scoped to the case at hand, and every run is logged in full. Those same logs satisfy the GDPR's accountability duty, the AI Act's obligations and your own debugging needs.
The EU AI Act applies in stages. The AI-literacy duty under Art. 4 has applied since February 2025, the transparency duties under Art. 50 since August 2026, and the transition periods for high-risk systems run into 2027 and beyond. A triage or order-entry agent with human review is not a high-risk system. High risk is AI that decides about people. If an agent drifts from sorting the applications inbox to ranking candidates, it has changed risk class, and the role is cut precisely to prevent that.
You are the deployer under the regulation. That means identity, permissions, data and approvals stay with you, and the people supervising the agent understand what it does. We answer for the code, the evals, the model migrations and the regressions. That split is written into the contract.
What operations and maintenance actually mean
Go-live is where the work starts. Model providers deprecate versions. An upstream system changes a field. A colleague edits a template and the agent suddenly produces something different. None of that is a bug in the agent, and all of it is a maintenance case.
That is why every agent we build comes with an eval suite of a few hundred historical cases with known-good results, which runs on every change to prompt, model or upstream system. Plus monitoring with alerts, cost and token budgets, a rollback to the last working version, and a monthly review against the agreed metric. What that means in detail, and how responsibility splits between deployer and vendor, is in the two guides operating AI agents and AI agent maintenance.
What it costs
Our prices are on the page. The first call takes 30 minutes and costs nothing. The discovery sprint is €2,900 at a fixed price and takes a week; it ends in the agent role, the evaluation criteria and a go/no-go recommendation with a costed roadmap. Deployments start at €7,900 setup, operations and maintenance at €2,400 a month. The sprint is credited in full against a deployment within 90 days.
What drives the price: the number of integrations, the state of your data, how much control you need — that is, how many action types require approval — and the volume. What does not drive it: the size of your company. The proposal after the sprint makes scope, setup, running costs, metric and exit explicit.
Why agent projects fail
It is almost never the model. MIT's Project NANDA examined 300 enterprise deployments and found that around 95% of GenAI pilots show no measurable effect on the P&L. RAND, after interviews with 65 experienced engineers, estimates that more than 80% of AI projects fail, twice as often as IT projects without AI. The reasons repeat. The agent lacks clean access to the systems where the work actually happens. Nobody defined what a good result is. The handover to a person is missing, and the first edge case leaves the job stuck. After go-live, nobody looks after it.
Our approach is cut to those four causes: the sprint supplies the definition of success, the integration supplies the access, the approval mode supplies the handover, the maintenance contract supplies the operation. What the engineering discipline behind it looks like is in shipping AI that survives production.
Why an engineering team
twigbit is a team of senior software engineers in Berlin that runs itself on agents. Sales, marketing, reporting and parts of development go through the same agents we ship. What we learn there about evals, context upkeep and permission models goes into the next project.
What we sell is software that moves a number, and the responsibility for it in production. At Projektron the support-triage agent returned 3.9× its cost in the first year; at A2Mac1 the agent found 27% cost-saving potential across the supply chains analysed. Both cases are below, with names and contacts. Ask them.
How to start
Bring a recurring workflow, or a product idea. In 30 minutes we work out whether it is clear, frequent and controllable enough for an agent, what integration or engineering could make of it, and what the smallest sensible first step would be: sprint, prepare, or deliberately wait.
