How it works

A model, a loop, and a list of permitted tools

That is the whole definition of an agent, and every vendor in this market has the same first two. The list is the product — and so is the gate standing in front of it.

The loop, drawn

An agent is not a magic entity. It is a model in a repeat-until-done loop, where each turn it can either produce text or ask to use a tool. Gibreen's contribution is everything drawn in amber and purple below — what tools exist at all, who may use which, and where the loop is made to stop.

The Gibreen agent loop A scheduler picks a due job and builds a prompt from the agent's charter. The model runs and either reads through a closed connector vocabulary, or proposes an irreversible act. Reads loop back into the model. Irreversible acts stop at a human gate; only after approval does the act go through the application's own logic. Everything is appended to a plain-text record. Scheduler a due job, every minute The charter remit · reach · gate a file you wrote The model Claude, on your account reason → act → observe Read connectors a closed list of operations ERP · files · mail · web observations return THE GATE a person decides approve · amend · refuse an irreversible act is proposed Your application its own logic runs one record at a time only if approved The record every run, every question, every decision, every refusal — plain text, version controlled, readable without a login
Green is reading and is allowed to run unattended. Purple is the stop. Amber is the part you write and the part you can audit.

Design decision one

The tool list is closed, not filtered

There is a weak version of agent permissions and a strong one, and the difference decides whether the security story survives a determined attacker.

✗ The weak version

  • The agent can call anything, and a rule says which calls are allowed.
  • The rule lives in the prompt: "you must not delete records."
  • A cleverly worded document in the agent's inbox can talk it out of the rule, because the instruction and the attack sit in the same context with the same authority.

✓ What Gibreen does

  • A fixed vocabulary of operations exists. Anything outside it is not refused — it has no implementation to reach.
  • The allow-list is re-applied inside the connector itself, after the agent has said what it wants.
  • Credentials live in the connector process. The agent never sees a secret, so no amount of persuasion extracts one.

Prompt injection is an unsolved class of attack. Every serious published incident has the same shape: untrusted content reaching a context window that also holds a credential. You cannot instruct your way out of it. The control has to be structural — which means the honest question to ask any vendor is not "is your agent secure", it is "what can your agent physically not do?"

Design decision two

Gates are per act, not per agent

Most human-in-the-loop implementations are a toggle: supervised or autonomous. That is the wrong granularity, because it forces a choice between an agent that is useless and an agent that is frightening.

A permission in Gibreen is attached to a business act, which is the unit your delegation of authority already uses:

The same agent, four different answers. This is the point.
ActReversible?Default
Read the overdue invoice listYesRuns unattended
Draft a chase emailYesRuns unattended
Send that email to the customerNoGate
Post a journal entry to the ledgerNoGate, and a second approver if you want one

The question a gate asks is not "do you approve?" — that produces rubber-stamping within a week. It states what will happen, what it is instead of, and what the agent is unsure about. A refusal is recorded with the same weight as an approval, because the refusals are the most valuable rows in the record.

Design decision three

The last mile — where agent projects actually break

Reading a business system is solved. Writing to one safely is not, and it is where the money and the damage both live.

Every ERP vendor's own agent writes through their own product's logic, because it is their product. Everything else in the market writes over the API and treats "has API access" as "can act safely". Those are not the same sentence.

The concrete example, from our own books

In an ERP, picking a customer on a quotation form triggers the logic that pulls their price list, their tax position, their fiscal position, their payment terms and their delivery address. Setting the same field over the API triggers none of it. The record saves. Nothing errors. The quotation is wrong on price and tax, and you find out when the customer does.

We ran scripted writes against our own accounting once. It produced hundreds of entries in the wrong journal, a landlord booked as a subcontractor, and a wave of reversals that all netted to zero. The interface would have stopped nearly every one of them. The interface is not a slower API. It is the control.

So Gibreen's rule, which applies to every agent, on every live system:

  • Read freely over the API. This is safe and it is most of the value.
  • Write only through the application's own logic, one record at a time, doing what a user's click would do.
  • Never in bulk, never around the back. No loops over records, no direct database access, no mass field updates, no scripted posting or reconciliation.
  • Where the correct path is genuinely a human clicking, the agent prepares a numbered worklist and a person clicks. That is a feature, not a failure.

We build this deeply for one system of record at a time. Today that is Odoo — because we implement it for a living and because we know, in measured detail, exactly how an agent breaks it.

Design decision four

The record is files, not a database

Gibreen's state — the agents, their charters, the jobs, the plans, the runs, the questions, the decisions — is plain markdown and TSV in a git repository. This looks primitive next to a product with a proper schema. It is deliberate, for three reasons:

01

You can read it without us

An auditor, a lawyer or a new operations manager opens a text file. There is no export, no API call and no vendor in the middle of the evidence.

02

Every change has an author and a time

Version control gives you the diff for free. "Who changed this agent's remit, and when" is one command, not a support ticket.

03

You can leave

If you stop paying us, you keep the record and it still opens. Lock-in through an unreadable data format is a business model we would rather not have.

The honest trade: files are slower than a database and they do not do concurrent writes well. We pay that cost on purpose. At the scale of one organisation's operational record, it has never been the bottleneck — and the property it buys is the one a regulator cares about.

Design decision five

We rent the engine and own the gate

Gibreen runs on Claude, and we do not pretend otherwise. The model vendors are shipping schedulers, memory, cost caps and orchestration as free platform features, and they will keep doing it.

So the rule we build to, with a date attached: assume every runtime primitive in Gibreen becomes a free feature of the underlying platform within eighteen months. We do not invest in the things the model vendor would naturally ship. We invest in three things they will not:

  • Approval at the granularity of a business act, mapped onto your actual delegation of authority.
  • A compliance-readable record of what was decided and what was refused.
  • One deep, correct connector into the system of record you actually run.

This is also why there is no visual agent-builder canvas, no marketplace, and no in-house memory layer. Those exist, they are free, and the best-funded company in the category already switched one of them off.

Talk to us

Start with a conversation, not a signup

Gibreen is not sold from a pricing table. Tell us which system of record you run and which job is eating your week, and we will tell you honestly whether this is a fit — including when it is not.

Goes to one mailbox in Amman. No list, no third party, no automated sequence.