In active development
An AI agent built to think, execute and evolve.
Not a chatbot. ABRAHAM AI is an agent designed to understand a project, use real tools, carry out the work, inspect what happened, test it and learn from what is verified — inside boundaries its owner sets.
An agent platform, not a chat window.
ABRAHAM AI is a persistent, multi-project agent platform. A conversation with it is a session: it is stored, it belongs to a project, and it continues across a restart. Nothing starts from an empty page every morning.
The model is one component, not the product. Around it sits the part that decides what to do — assemble the context for this step, choose a tool, run it, read what came back, reason about it, and take the next step or stop and ask.
It is built to work across projects and technologies rather than being tied to one application or one language. A project is a registered directory with its own knowledge, its own sessions and its own grants, and the boundary between two projects is enforced in the database rather than by convention.
Jebrex builds, owns and operates it, as it does every other product on this site.
From conversation to execution.
The difference between an assistant and an agent is what happens after the answer. An assistant describes the change. An agent makes it, looks at the result, and decides what to do next.
- Reasoning
- Tool use
- Real execution
- Project understanding
- Knowledge
- Memory
- Testing
- Security
- Auditing
- Continuous improvement
None of those is much on its own. Together they are what lets a request end in work that was actually done — and in a record of how it was done.
One run, eleven moves.
A run is a bounded sequence of steps. This is the shape of one.
-
01
Request
A message in a session, and the session belongs to a project.
-
02
Understand
The request is read against the project’s rules, the session so far, and what is already known.
-
03
Plan
The next step is decided. Not the whole future — the next step.
-
04
Select tools
Only the tools this run is permitted to use are offered to the model at all.
-
05
Execute
One shared executor runs the call, under a timeout and a ceiling on what it may return.
-
06
Inspect
The result comes back as data: an outcome, a summary, the sources it read, and an audit record.
-
07
Reason
The result is fed back into the next step. An agent that cannot see what its tools returned only repeats itself.
-
08
Test
Where the work is code, running the project’s own test command is a terminal call like any other — recognised, classified and bounded.
-
09
Review
Every invocation, decision and refusal is written to an audit trail that cannot be edited afterwards.
-
10
Learn
What proves useful is written down as knowledge or memory, with where it came from attached.
-
11
Continue
Or stop — and say which limit it reached, rather than presenting itself as finished.
Every run is bounded before it begins: a ceiling on steps, on wall-clock time, on total tool calls, and on repeats of an identical call. Each limit is checked before the action it bounds, never after — a loop that discovers it has made one tool call too many has already made it.
Built to reach the real software ecosystem.
Each of these is described as it stands today. Where something is reachable but not integrated, or built but not yet proved against the live thing, it says so.
-
Implemented
Files & codebases
Lists, reads, searches, writes, edits, moves and deletes files strictly inside the active project root — plus read-only lexical analysis of a project’s languages, structure, exported symbols and declared dependencies.
-
Implemented
Terminal
Runs one executable with no shell, inside the project, classified before it runs. An unrecognised command is refused rather than run on the assumption that it is harmless.
-
Implemented
Web research
Search returns ranked candidate sources and says outright that they are unverified pointers. The reader fetches one page through a guarded fetch and hands the text back labelled as external content.
-
Implemented · not re-tested against a live browser
Browser
Attaches over the DevTools Protocol to a browser you are already running and reads the rendered page, its requests, or one expression. ABRAHAM AI ships no browser of its own.
-
Implemented · live calls not in the verified set
GitHub
Reads repositories, branches, pull requests and code search; creates branches, forks and pull requests. The credential is held by the client and never passes through the model.
-
Implemented
HTTP APIs
Calls the APIs you declare as connectors. The model picks a connector and a path under a declared prefix; it cannot pick a host, a method you did not list, or a reserved header.
-
Reachable, not integrated
Deploy tools, Vercel included
There is no built-in Vercel integration. Vercel is reachable as a declared API connector, or through the terminal, where it is classified as a deploy command — which needs the always-gated deploy capability and an approval for every call.
-
No dedicated integration
Databases
There is no database tool. A project’s database is reached the way the project itself reaches it: through code the agent runs, or through an HTTP API you declare. ABRAHAM AI’s own store is SQLite.
-
Implemented · not verified against a live repository
Git
Repository state is read through a guarded client for project context. There is no Git tool and git is refused at the terminal, because repository mutation has its own path through the permission model.
-
One adapter implemented
AI models
The provider sits behind one interface and the agent core imports no vendor SDK, so a second model is an adapter rather than a rewrite. One adapter ships today: DeepSeek. ABRAHAM AI is the product; DeepSeek is a model it currently runs on.
It learns — and it keeps track of what it is allowed to believe.
Continuous improvement here means something narrow and checkable. ABRAHAM AI accumulates knowledge and memory from the work it does, and the record says where each piece came from and how far it can be trusted.
Anything extracted from the web arrives as a candidate. It becomes trusted only when the owner promotes it, and only trusted knowledge is treated as true. Everything else stays what it was: material, with a source attached.
Memory is the durable half — facts about the owner’s preferences and the projects they work on, assembled into each run’s context within a declared budget. The context builder produces a manifest of what it included, so an answer can be traced back to the knowledge and the memories behind it.
It does not rewrite itself. There is no path by which a run edits the rules it runs under, and the scheduled research and consolidation jobs cannot silently change the security rules they run beneath.
- Candidate to trusted, by the owner’s hand.
- External content is data, never instruction — however imperatively a page is phrased.
- Project isolation is a database constraint: a mis-scoped record cannot be stored at all.
- Scheduled research and consolidation run without being asked, and are recorded when they do.
A tool declares what it needs. The platform decides what it gets.
Eight tools ship today, and the agent core does not know what any of them do. A tool is data: an identifier, an input schema, the capabilities it needs, a timeout, whether it can change anything outside the process, and which of its inputs are summarised into the audit record.
That is what makes the limits enforceable rather than aspirational. Authority is resolved from the declaration, so a read never carries write authority — and a refusal happens before the handler runs. The tests assert the file was not written, because a refusal that has already written the file is not a refusal.
Availability is probed, not assumed. A tool that cannot work right now reports itself unavailable with a reason you can act on, instead of failing at the moment it is called.
Security is what decides whether any of this is usable.
ABRAHAM AI is given a terminal, a filesystem and a network. These are the controls that make that a considered decision rather than a reckless one.
-
Permissions
Twelve capabilities and four modes. Nothing is granted by default, reads included, and two capabilities — deploy and secrets — stay gated whatever the mode allows.
-
Approval gates
A mutating action asks on the run’s own stream and waits for an answer. Approve and it proceeds; refuse and it does not happen.
-
Terminal controls
No shell, so there is nothing to inject into. Shells, privilege escalation, git and unrecognised binaries are refused, as are arguments naming a path outside the project.
-
Filesystem containment
Every path is resolved lexically and against the real filesystem, and the operation runs on the resolved path. The repository metadata directories are protected against every spelling Windows accepts, deletion included.
-
SSRF protection
Private, loopback and link-local addresses are refused by default, and the check is repeated on every redirect hop — validating only the first URL is how this defence is usually defeated.
-
Browser safety
A navigation URL passes the same policy as any other outbound request, before the page is opened and again wherever a redirect lands. A refused URL is never navigated.
-
Secret protection
Credentials never appear in source, prompts, logs, audit records or model context. They are attached to an outbound request server-side, and child processes do not inherit them.
-
Auditability
The audit trail is append-only through its own API. Permission, security and deployment records are never aged out, and a record can never be removed one at a time.
In development and testing.
ABRAHAM AI is in active development and testing. It is being built and hardened deliberately rather than rushed, and it is not yet available to buy or to sign up for.
If you would like to hear when it opens up, tell us — we will let you know when it is ready.
The next things, stated as intentions.
None of this is on the page as a capability. It is what the architecture was shaped for.
-
A second model provider
The port exists and the agent core imports no vendor SDK, so a second adapter is an implementation rather than a redesign. Today only DeepSeek is implemented.
-
More tools, same contract
A tool declares what it needs and the existing permission model decides. Adding one should change no security code — that is the test of whether the model was right.
-
Learning with a surface
The learning cycle runs today and is recorded. Giving it a screen turns what it found into something you read rather than something you infer.
-
More autonomy, inside the model
Wider authority is something the capability and approval model has to grant, not something that arrives around the side of it.
Want to talk about it?
Tell us what you would want an agent to do inside your own projects.