Sber unveils three open-source tools for AI agents and JVM applications

An AI agent wrote the code but lost track of the architectural constraints. A service updated an order, crashed before sending an event—and a connected system never learned about the change. Sber's roundup presents three open-source tools for engineering problems like these: HG SDLC, Spring AI GigaChat, and Schedulex. They address different parts of the workflow: passing context between agents, connecting a model to an application, and executing background tasks after failures.

The most useful way to read this announcement is through a concrete question: which parts of the infrastructure does your team currently maintain itself, and could an existing project reduce that work? The published description provides enough technical detail for an initial assessment. But the efficiency estimates remain claims made by the authors.

HG SDLC: handing an agent a task together with its context

Consider a routine enhancement: an analyst prepared the requirements, a developer chose the architecture, an agent changed the code, and tests found a bug. The task now needs to go back for revision, with the agent receiving the requirements, constraints, and test results. If all of this lives in separate chats, a person has to keep the workflow connected.

HG SDLC lets teams describe the workflow as a YAML graph. It contains nodes with agent assignments, automated checks, and points where a human makes the decision. The orchestrator stores context, artifacts, and execution history, manages transitions, and allows work to return to an earlier stage.

According to the team, the tool runs on top of coding agents compatible with Agent Client Protocol. The listed requirements for running it locally are Java 21, Node.js 22, PostgreSQL, and a compatible agent. This is a separate infrastructure component that also needs configuration and maintenance.

The authors estimate a 16–30% improvement in development efficiency from combining agents, specification-driven development, and HG SDLC. They cannot isolate the orchestrator's own contribution. It would therefore be premature to treat that figure as a promised speedup for your team. The first thing to test is how many manual context handoffs actually disappear.

Spring AI GigaChat: integrating a model into an existing application

The second project targets teams using Java or Kotlin and Spring Boot. Writing a direct request to a model is straightforward. Then come conversation history, document search, function calls, streaming responses, and metrics. Maintaining all of this in a separate integration layer quickly becomes a task in its own right.

Spring AI GigaChat is packaged as a Spring Boot Starter and connects the GigaChat API to Spring AI interfaces. The application accesses the model through ChatClient, while related ecosystem components help manage documents, message history, and tools.

A straightforward use case is an internal documentation assistant that answers an employee's questions and calls an application function when needed. Business logic remains Java code; model integration goes through Spring AI. The article also describes the @GigaTool annotation for declaring functions available to the model.

Before integrating it, teams need to check compatibility between the versions of the starter, Spring Boot, and Spring AI. The authors specifically highlight the impact of API changes on the integration. The open-source library also does not remove the need to configure GigaChat API access and trust in server certificates.

Schedulex: surviving restarts and preserving data consistency

The third tool handles background work on the JVM. The key example is a service that changes an order's status and creates a task to send an event within a single transaction in a shared database. If the transaction rolls back, neither change is saved. After a successful commit, the task record remains in the database even if the application restarts.

Schedulex offers individual tasks, workflow graphs, and CodeFlow—a way to describe a workflow in ordinary code, with conditions, waits, and parallel branches. According to the authors, CodeFlow recovery relies on a log of step results and state stored in the database. When updating an application, teams need to account for compatibility between new code and the saved history.

The boundary of the guarantee matters: a database transaction does not make an external HTTP call atomic. If the recipient processed the request but the sender failed to record success, a retry may create a duplicate. External operations therefore need idempotency—the ability to handle repeated requests safely.

The authors report around 30.7 thousand executions per second, but with empty handlers and tasks created in advance. This is not a forecast of a real service's performance.

A practical next step is to choose one troublesome scenario: context loss, model integration, or a background process restarting. Testing it will provide a stronger basis for choosing a tool than an overall speedup figure.