Agents as Code
Agents as code is the practice of defining AI agent behavior, tools, memory, and workflow logic entirely in source code - so agents are versioned, tested, reviewed, and deployed through the same engineering practices as any other software system.
KEY TAKEAWAYS
- Agents as code means agent behavior lives in a repository - not in a visual builder, a database of configurations, or a vendor dashboard.
- Code-defined agents are reproducible: the same commit produces the same agent behavior in every environment - dev, staging, production.
- Agents defined in code can be reviewed in pull requests, tested in CI, rolled back with git revert, and audited through version history.
- Visual or config-driven agent builders trade control for convenience - agents as code trades convenience for precision and production reliability.
- Calljmp is built for agents as code - agent logic, tools, memory, and workflows are defined in TypeScript and executed by the Calljmp runtime.
WHAT IS AGENTS AS CODE?
Agents as code is a development philosophy that treats AI agent definitions as first-class software artifacts. Every aspect of an agent's behavior - its instructions, its tools, its memory configuration, its workflow logic, its error handling - is expressed in source code, committed to version control, and deployed through standard software engineering processes.
The alternative is configuration-driven or visual agent definition - building agents through dashboards, drag-and-drop interfaces, or JSON configuration files managed outside a codebase. These approaches lower the barrier to entry but remove the engineering controls that production systems require: version history, code review, automated testing, environment parity, and programmatic deployment.
Agents as code does not prescribe a specific language or framework. It prescribes a practice: agent definitions belong in the codebase, not in a vendor's UI.
HOW AGENTS AS CODE WORKS
- Define agent behavior in source files. The agent's instructions, tool definitions, memory configuration, and workflow logic are written as code - functions, classes, or typed configuration objects - in the project repository.
- Commit to version control. Agent definitions are committed to git alongside the application code they serve. Every change to an agent is a diff, reviewable and attributable to a specific author and timestamp.
- Test in CI. Automated evals and unit tests run against agent code on every pull request - catching regressions before they reach production. The agent is a software artifact subject to the same quality gates as any other module.
- Deploy through standard pipelines. Agent code is deployed using the same CI/CD pipeline as the rest of the application - no separate dashboard login, no manual configuration step, no environment drift between staging and production.
- Roll back with git. If a deployed agent change degrades behavior, rolling back is a git revert and a redeploy - not a manual undo operation in a visual interface with no change history.
- Compose and reuse. Code-defined agents can import shared tool libraries, reuse memory configurations, and compose with other agents - using the full expressiveness of the programming language, not the constraints of a visual builder.
The critical infrastructure requirement: agents as code only delivers its full value when the runtime executing the code supports the same deployment model - environment variables, typed configuration, programmatic initialization. A code-defined agent deployed to a runtime that requires manual dashboard configuration reintroduces the fragmentation agents as code is designed to eliminate.
COMPARISON TABLE
| Dimension | Visual / no-code builder | Config-driven agents | Agents as code |
|---|---|---|---|
| Agent definition location | Vendor dashboard | JSON / YAML files, often outside repo | Source code, in the repository |
| Version control | None or limited export | Partial - config files only | Full - every change is a commit |
| Testability | Manual, in the UI | Limited - config not executable | Full - unit tests and evals in CI |
| Environment parity | Dev and prod often diverge | Depends on config management | Guaranteed - same code in all environments |
| Best for | Non-technical builders, prototypes | Simple agents with stable behavior | Production agents requiring engineering rigor |
| Main trade-off | No code required, but no control | Familiar format, but limited composability | Requires TypeScript skill, higher initial investment |
What This Means for Your Business
The hidden cost of building agents in visual tools is not the tool itself - it is what happens six months later, when the agent needs to change and no one can tell what it currently does, who changed it last, or why it behaves differently in production than in the test environment.
- Your engineering team owns the agent the same way they own the product. Code review, version history, rollback - these are not bureaucratic overhead. They are the mechanisms that prevent a bad agent change from reaching users undetected.
- Onboarding a new engineer to the agent takes hours, not weeks. An agent defined in code is readable in an IDE, searchable in the repository, and understandable through its commit history. An agent defined in a vendor dashboard requires access, navigation, and institutional knowledge that does not transfer.
- Incidents become recoverable, not catastrophic. When an agent change breaks production behavior, a git revert and a redeploy restores the prior state in minutes. Without version control, the prior state may not be recoverable at all.
Calljmp executes TypeScript agent definitions directly - the same code that runs in development runs in production, with no dashboard configuration step between commit and deploy.
Ready to define your agents like the software they are?
Calljmp executes TypeScript agent definitions directly - version control
Start free - no card neededFAQ
What is the difference between agents as code and using an agent framework like LangChain?
A framework like LangChain provides abstractions for writing agent logic in code - it is compatible with the agents-as-code practice. Agents as code is a broader philosophy about where agent definitions live and how they are managed - in version control, tested in CI, deployed through pipelines. You can use LangChain and still violate agents-as-code principles if your prompts live in a database, your tool configurations live in a dashboard, and your deployments require manual steps outside the codebase. The practice is about the full lifecycle, not just the code that runs.
Does agents as code require TypeScript specifically?
No - the practice applies to any language. Agents can be defined as code in Python, Go, or any language the team uses. TypeScript is a common choice for web and full-stack teams because it provides strong typing for tool definitions and agent configurations, catches schema mismatches at compile time rather than runtime, and integrates naturally with the JavaScript ecosystem most frontend and backend teams already use. The language is a tool choice; the practice is language-agnostic.
How does agents as code handle prompt versioning?
Prompts are strings in source files - they are versioned, diffed, and reviewed exactly like any other code. A prompt change is a pull request. The diff shows exactly what changed. The commit message explains why. The CI pipeline runs evals against the new prompt before it merges. This is the core advantage over prompt management in external databases or vendor dashboards, where change history is absent or opaque. Teams that treat prompts as code gain the same change control over agent instructions that they have over application logic.
Can non-technical team members contribute to agents defined as code?
With the right tooling, yes - but with more friction than a visual builder. Product managers and domain experts can edit prompt files directly in a repository UI like GitHub, submit pull requests, and have engineers review and merge. This is slower than a dashboard but produces a reviewable, versioned change rather than an untracked edit. Teams that need frequent non-technical contributions to agent behavior sometimes extract prompt content into structured configuration files - keeping logic in code while making content editable without a development environment. Calljmp's TypeScript-native model is designed for developer ownership, with non-technical contributions handled through reviewed configuration files rather than direct runtime access.