Skip to content
Ideasforge
ES
Services Projects About us Blog Contact

Services

Guide: AI agents AI agent development AI workflow automation Conversational AI Internal documentation GDPR-compliant AI AI for small business AI for real estate AI for accounting firms What an AI agent costs
We are the forge of your ideas

Stop searching your systems. AI agents that answer and act.

At Ideasforge we design and maintain custom AI agents for mid-size and large companies, on your infrastructure and measured before every change.

Tell us your challenge

Companies we work with

Industry, agriculture, real estate, healthcare and professional services.

  • Stanton
  • The Dazzwebs Studio
  • AIMO
  • Barceloneta Premium
  • Savian
  • Baba
  • Wazzy
  • Amigo & Amigo
Industrial company

Guided troubleshooting for whoever is at the machine

6 agents
Guided troubleshooting for whoever is at the machine
Savian

Anyone on the team, asking their own data

From hours to seconds
Anyone on the team, asking their own data
Stanton

The invoices stopped being typed

2 agents
The invoices stopped being typed
Barceloneta Premium

The filter that works while the office is closed

+3 hours
The filter that works while the office is closed
Wazzy

Booking an appointment without calling or waiting

103 controls
Booking an appointment without calling or waiting

Services

What we build

Four capabilities for mid-size and large companies. For SMBs, the same pieces in fixed-scope packages.

For mid-size and large companies

For small and mid-size businesses

Tell us your challenge

Commitments

Why Ideasforge?

Three commitments a subscription cannot give you.

  • Observability by default

    Every change goes through the test suite before it ships, and we keep measuring every week afterwards. If one of them stops understanding queries well, we know before you do.

  • The code is yours

    We hand you a system, not a black box. If you decide to take it elsewhere tomorrow, you can.

  • Security by default

    The model does not write the queries that reach your systems, it picks from options we have already reviewed. Each person signs in with their company account and your data lives wherever you decide.

We measure every change before it ships to production

Your provider updates the model your system runs on without changing its name, your documentation keeps growing, and the system that answered well yesterday starts answering badly today.

Tell us your challenge
  • Tests before going live If a change lowers quality, it never reaches your users.
  • We know why it answered that What it consulted and what it discarded is on record.
  • We count what it could not do Every unanswered question is logged with its reason.
  • We watch your provider If they update the model on their own, we notice first.
  • It flags partial answers It states what it queried and what was left out.

The most expensive failure sets off no alarm, it is a flawless answer (that happens to be false).

The failure that does not look like one

A manager asks how much field 4 produced last month. The assistant returns a good-looking, well-written figure. That figure is wrong. No log shows an error. The system did exactly what it believed was right. That is the failure that keeps us up at night, because it does not look like a failure.

The ground moves on its own

The disconcerting part is that the model name stays the same while what sits behind it does not. Researchers at Stanford and Berkeley measured this in 2023. They sent the same questions to the same commercial model in March and in June, calling it by the same name over the same connection. On one of the tasks, accuracy fell from 97.6% to 2.4%. Nobody on the customer side touched anything. The provider had updated the model underneath. That is why measuring is not a quirk of ours, it is the only way to know that what worked in March still works in June.

Why we can store the decision

Against that, looking at error logs is useless, because there is no error to look at. And this is where the way we build changes things. If the decision lives inside the model, there is nothing to store, only a piece of text that came out. So in our systems the model does not decide. It understands the question and hands over a JSON contract with what it understood. A script validates it, decides and answers. That decision can be stored whole: what it understood, what it asked for, what the validator rejected and why. We cover it in detail in why we don't like agentic architectures.

How we were getting it wrong

At first we reviewed the model's decisions by hand, one by one, reading execution histories after the fact. It did not scale and it was no baseline either, because a system that is not deterministic does not answer the same way twice. Reviewing isolated cases tells you nothing about whether the whole got better or worse. The leap was taking the decision out of the model and putting it in code, because deterministic things can be tested in bulk. Today every change runs against a battery of real questions with their correct answer already recorded. If it breaks one that used to pass, it does not ship.

What happens to a change before it ships
A new change
The usual questions
The new ones it brings
Any failures?
Back to review
Goes to production
fails passes
The usual questions are not retired when a change arrives, the new ones are added to them. That is why an improvement in one place cannot break another without us finding out before it ships, which is while it is still cheap.

What the person asking sees

Some of what we measure is shown to the person asking, and that was deliberate. In one of our assistants every answer opens by stating which period it queried, because we found that 'last month' meant different things to different people. And if a data source is unavailable, the system answers with the ones it has and says which was left out. We prefer an answer that admits what it is missing to an incomplete figure that looks complete.

Measuring does not stop the system from failing. It stops it from failing in silence.

What we don’t promise

We don’t promise the system will always get it right. We promise we will find out before you do and leave a written record of why it failed, so the same error does not slip past twice.

No black box, no lock-in

AI providers change prices and retire models. Some platforms shut down outright. The system we hand over is designed so that none of that news ever becomes your problem.

Tell us your challenge
  • Repository under your name From day one, not at the end.
  • You are not buying a subscription You are buying a system that stays in your house.
  • A real handover Operations manual and sessions with your people if you want them.

Vendor dependence is rarely in the contract. It lives in the day-to-day.

Where it really starts

It begins when the instructions that govern the system are known only to whoever wrote them and nobody else can check whether a change makes them worse. It grows when documentation describes what someone meant to do instead of what ended up being done. By the time you want to switch providers, no contract is stopping you, there is simply nobody left who can explain how the thing works.

And meanwhile the ground moves

Providers retire models regularly and they do it in writing. Anthropic publishes its deprecation schedule and gives sixty days of notice. On 15 June 2026 Claude Sonnet 4 and Opus 4 stopped working, so from that date any call to those identifiers fails. This is not an accident or bad practice, it is how the sector works. The question is what each of those retirements costs you, because when a provider retires a model, that should not affect you.

What is inside the repository

Everything that defines the system behavior lives versioned in your repository: the model instructions with their change history, the tests with their correct answer recorded, the operations manuals and an incident catalog. That catalog is the piece technical teams appreciate most and the one almost nobody asks for, because it does not say how each problem was fixed, it says how it is recognized from the outside, which is what helps the next time the system acts strange.

Swapping models is proven, not promised

Saying one model can be replaced by another is easy. We check it before we claim it. When we considered swapping the model in one of our systems for a cheaper one, we ran both versions through the same set of questions with their correct answer recorded. The cheaper one lost ten points of accuracy and on the questions where it had to choose between two similar options it fell from 89% to 44%, so we rejected it with those numbers in front of us. That same check decides which model goes where, which is why our production systems do not all run on the same provider.

Neither a closed product nor a subscription

An off-the-shelf product decides for you where your data lives, what can be integrated and when the price goes up. What we hand over runs on the cloud we set up for you, under your name. The only outbound path is the calls to the model, which you approve one by one. If your committee decides that not even those may leave the perimeter, that is a conversation we have on the table from day one, with what it gains and what it costs.

Who we write the documentation for

Documentation is written with one specific person in mind, and it is not you. It is whoever maintains this in two years, someone who sits in none of today's meetings and will arrive without context. If what we leave them does not come with something they can run to check it, it is no use to them. We hold ourselves to the same rule we hold you to.

What we don’t promise

We don’t promise you will never need us. We promise that the day you decide to move on you won’t have to ask us for anything, because you have had it all at home since day one.

Security that does not depend on the model getting it right

Where the data lives and who gets to touch it are decisions we make at the start, not at the end. Your security committee will ask eventually, and we would rather have the answer before the meeting.

Tell us your challenge
  • The model does not write queries It fills a closed form and the code runs it.
  • It only talks to what you approve Contained by permissions, not filters.
  • GDPR Real deletion and legal retention periods met.

The model decides, but it is never the authority.

Why a filter does not fix it

A language model receives the instructions we give it and the text that reaches it from outside through the same channel, with nothing separating one from the other. So someone can slip into that text something the model reads as a new order and follows without realising it has switched sides. Classic security solves this by separating data from instructions. Here that separation does not exist, which is why prompt injection tops the OWASP risk list for language-model applications for the second edition running. In December 2025 the UK’s national cyber security centre went further and warned it may never be fixed as a category, asking defenders to stop waiting for a patch and work on reducing the damage instead.

The usual setup leaves the door open

What makes an assistant dangerous is not what it knows, it is what it can do. Security people talk about three ingredients that are harmless apart and dangerous together: access to private data, input that comes from outside and a free path to act on your systems. The first two are the reason the assistant exists, so the third is the one to cut. The most common setup today does the opposite, because it plugs the model into the database through a connector that lets it write the queries itself (the now-famous MCP connectors). From that moment it can write any query the language allows. The only thing stopping it is a sentence in its prompt, along the lines of “do not query the payroll table”. And this is not a guarantee, it is a polite request.

The model chooses, the code executes

Our data assistant, and most of the ones we build, are built the other way round. The model does not write the query. It fills in a closed form (a JSON contract) with the fields we defined and a program reads that form and builds the query that reaches the database. That program only knows how to build the queries we taught it, so no other one can come out of there. The plant assistant we built for an industrial company works the same way with documents. The model picks a label from a closed list and the code retrieves the official text attached to it. A malicious message can, at most, pick the wrong option from a list we have already reviewed.

The model interprets, the code decides
User question
Model
Validator
Blocked
Parameterized query
Database
JSON contract rejects accepts
The model never reaches your systems. It interprets the question and hands over a contract, and from there the code decides, and the code does behave the same every time. The worst a malicious message can achieve is a wrong pick from a list we have already reviewed.

Never more permissions than the person

The assistant has no all-powerful credential of its own. Queries to internal systems are fired by the user with their usual permissions, the same ones they already have across the rest of the company’s applications. And when in doubt it blocks. If the permission list arrives empty, the answer is a flat no instead of default access.

Some limits are not technical

In one of our assistants anyone with permissions can look up production at their sites, but the system will not answer about the hours worked by specific people, lateness or absences. Some of those columns sit in the database and are simply not exposed. The restriction lives in the code, not in the hope that the model behaves. The tool is there to run sites, not to build a file on anyone.

Health data, the highest bar

At Wazzy we handle health data, which European regulation places in the most protected category there is. We do store personal data, because without it there is no service. What changes is how. Encryption runs field by field and deletion respects the five years that clinical record retention requires, a legal deadline rather than a preference of ours. The bar is set for us by the European AI regulation and by data protection law.

A shortcut of ours and how we closed it

One of our systems had a test build that skipped the login. It was created so changes could be tried without authenticating every time, it was documented and it was flagged for removal, which is exactly the kind of thing still sitting there two years later. What we did was put a dry-run mode inside the authenticated path that does the same job, so the shortcut was left with no reason to exist. Since then every temporary fix we write down carries its own expiry date.

The question is not whether someone will try to trick the model. It is what the model can actually do once they succeed.

What we don’t promise

We don’t promise an invulnerable system, because there is no such thing. We promise to apply the highest security our AI architectures allow and to keep a tight grip on everything the language model can and cannot do.

How we work

Four steps to take AI from idea to daily use.

  1. Explore

    We map with you where the pain is and where AI moves a metric. We do not start with technology, we start with your business.

    What you walk away with

    • A map of where AI helps and where it does not
    • The real state of the data it would need
    • The constraints to respect from the start

  2. Prioritize

    Out of every possible use case we pick the ones with tangible ROI that are doable today. If something does not pay off, we tell you.

    What you walk away with

    • The use cases ranked by what they return
    • What we ruled out, with the reason written down
    • A first bounded case to start with

  3. Implement

    We build a production system, not a prototype. With your organization’s accounts, your integrations and your security rules.

    What you walk away with

    • The system running on your infrastructure
    • The repository under your name from day one
    • The test suite with its correct answers recorded

  4. Optimize

    We measure how it behaves week after week. We tune it, extend it and absorb new models when they ship.

    What you walk away with

    • Weekly measurement with the result in plain sight
    • The incident catalog, which says how each fault is recognized
    • Every change goes through the tests before reaching your users
Start with step 1

We integrate with your stack

SharePoint, Confluence, Azure, SAP, ERP, CRM and models from OpenAI, Anthropic and Google. Your systems stay put; AI flows through them.

Tell us your challenge

Blog

What we discover while building AI in production with our clients.

Visit blog

The shiny toy

Four layers between your company and the one next door

Here is a secret: I don't like agentic architectures

Data before prompts

The silent zero

Starting an AI project is easy. Keeping it alive, nearly impossible

The symptom signature beats the fix

The auditor that trusts no figure

What your assistant does when a tool goes down

Measure AI by profit, not by productivity

Two kinds of "no" that are not the same

The shiny toy

The AI project that dazzles in the demo and dies in a drawer has a name and an antidote. A three-signal test to tell a tool from a whim.

Read more

FAQs

The questions we usually answer before we start.

Does my data leave my infrastructure?

Only if you decide so. We deploy on your cloud or your own servers, with your organization’s accounts, and the system stores the minimum it needs. The only outbound path is the calls to the model provider, and you approve which ones happen and what travels in them.

Who owns the code you build?

You do. We hand you the repositories, the documentation and the architecture from day one. No black box, no vendor lock-in.

How do you know AI keeps working after delivery?

In two ways. A test suite runs before every change and blocks it if quality drops. Once live, we keep measuring every week. If the system stops understanding a question, we catch it before it reaches the end user.

Do you only work with large enterprises?

No. We have dedicated packages for small businesses (customer support, lead qualification, document automation) with the same engineering we use on enterprise projects.

Do you work as an AI automation consultant?

Yes, as the first phase of every project. Before anything is built we study your processes and your data and tell you where an agent pays off and where it does not. If we see no return, we say so and it ends there. And when there is one, the same team that recommended the system builds it and operates it, so the advice answers for its results.

Contact

Tell us your challenge.

We reply within 24 business hours. No forty-slide sales deck.

Describe it the way you would to a colleague. You do not need to know which technology solves it.

If you already know you want to start, the exploration form collects what we need to get going.