Calling your existing programs
You will not need to rewrite what already works. Agents written in AEL, the Agent Engineering Language, will call your existing Python, JavaScript, Java or .NET programs, shell commands and operating-system operations as typed tools, with runtimes you provide, locally or on a remote worker.
Status
Planned for AEL Beta 0.0.1. AEL is not available yet.
Package names on this page are preview naming and may change before launch.
The packages
| Package | What it will run |
|---|---|
execution/process | A program, started with a list of arguments. No shell is involved. |
execution/shell | A command, through a shell you choose by name. |
execution/terminal | An interactive terminal session with a program. |
execution/python, execution/javascript | Your Python or JavaScript programs, scripts and modules. |
execution/jvm, execution/dotnet | Your Java or .NET programs. |
execution/remote | Any of these on a remote worker that you authorize. |
You will add only the ones you use, with ael pack add (command names may change before launch):
ael pack add execution/python
Like every AEL package, these will be written in AEL and ship as compiled, verified AEL, with no bundled native code and no install scripts. The programs they start are yours: the packages will carry no Python, JavaScript, Java or .NET code of their own.
A program as a typed tool
From your agent's side, an existing program will look like any other typed operation: it will take typed arguments and return a typed result.
# nodes/score.node.ael
node score(input: Claim) -> RiskScore {
return run_scorer(input);
}
fn run_scorer(input: Claim) -> RiskScore {
# Runs your existing scoring program through execution/python,
# with typed arguments, a deadline and output limits.
}
A model-driven node will be able to offer the same call to its model as a tool, with its own permission; see Tools and MCP. The exact exports of each package will be confirmed before launch. Until then, the body of run_scorer is a placeholder, as A first agent explains.
What each call declares
| Part | Meaning |
|---|---|
| Program | The script, module, application file or executable to run, and its entry point. |
| Runtime | The runtime and version it needs, checked before the call runs. |
| Arguments | A list of typed values, never joined into one command line. |
| Environment | The working directory and the environment values you list; secrets passed by reference. |
| Permissions | The folders, network destinations and process rights the program may use. |
| Limits | A deadline, output size, CPU, memory, process count and temporary storage. |
| Result | The type its output must decode into, and your checks on it. |
Results you can rely on
- Exit will not mean success. A program that exits normally will still have to produce output that decodes into your result type and passes your checks.
- Every outcome will be typed. A failure status, a program stopped by the operating system, a program that could not start, a deadline passed, a cancellation, a resource limit and unreadable output will be separate outcomes.
- Arguments will stay data. A file name with spaces, quotes or a leading hyphen will stay one argument. Only the shell package will read shell syntax, and only in the command text you give it.
- Output will be bounded. Standard output and error will be bounded byte streams; when output passes its limit, the result will say how much was kept and, where it is known, how much was produced.
- Cancellation will be thorough. Cancelling a call will stop the program and the programs it started, first gracefully, then by force after a grace period.
- Limits will be real or refused. Where a platform cannot enforce a limit you asked for, the call will be refused rather than run without it.
Runtimes you provide
Each call will name the runtime it needs, and AEL will check the runtime's identity and version before running anything. It will not fall back to whatever happens to be installed.
- On your machine or server, you will install the runtimes your programs need.
- In a minimal container image, there will be no shell, Python, Java or .NET unless your deployment includes it deliberately; the alternative will be a remote worker.
- On a remote worker, the program will run on a machine you operate. The worker will be authenticated, receive only the permissions, remaining budget and deadline of the call, and keep the caller's tenant identity across reconnects. If the connection is lost after a call started, its outcome will be reported as unknown, and work that cannot be repeated safely will never be run again automatically.
- On the smallest boards, there will be no processes: a call will need a gateway, and without one the build or deployment will be refused before anything runs.
Starting a runtime takes real time, and that time will be reported like any other.
Isolation
Permissions will keep your own program from reaching what it should not. They will not be a sandbox for a hostile program: run code you do not trust in isolation, for example on a remote worker you dedicate to it.
Reports
Time and token usage will be reported by default on every channel. The time a call takes will be measured on your side. Model tokens that your external program uses on its own will be reported as unknown unless they are measured; they will never be guessed from its output.
Related
- Files and processes: the full reference for files, processes and their outcomes.
- Effects and capabilities: how permissions are granted and checked.
- Tools and MCP: starting a local MCP server as a separate process.