ProtoMolt connects gRPC, MCP, Kafka, ACP, connectors, sinks, and agent chat in one
ecosystem. Its Java engine coordinates services and agents across languages through
shared protobuf contracts. Data flows through synchronous calls and asynchronous
workflows, with recorded evidence and receipts for completed work.
The engine coordinates participating services over gRPC, with tooling for
Java and 12 other language ecosystems.
Agents connect through MCP or ACP; HTTP clients can use the JSON interfaces.
Deployment options include Linux containers for AMD64 and ARM64 and a packaged server
for Apple Silicon Macs. The library catalog describes the
individual building blocks; the same contracts connect them across services and tools.
Language-neutral APIsSync and async workflowsAgent toolsApache 2.0
Overview. Connect your services and agents to a common coordinator.
Describe their inputs, outputs, and rules in protobuf, then compose their operations into
workflows. ProtoMolt uses those contracts for discovery, mapping, validation, execution,
and review across the participating systems. Connectors bring data in, sinks deliver it,
and the agent chat and task console let people and agents guide the work.
A caller can define the result it needs as a protobuf message with validation annotations.
Structured generation turns that descriptor into model instructions and an output schema,
then parses and validates the response before returning a successful result. In delegation,
a task can declare a typed deliverable and named checks. The deliverable must validate,
and the candidate must carry passing evidence reports for those checks before review.
This is useful beyond agents. The same validation library can check application data,
gRPC interceptors can enforce rules at call boundaries, and projections can describe how
one message becomes another. Follow the contract through the system.
Three ways to use the contracts
Correct and prepare data. Bring in records through
Kafka or connectors. Compose mappings, projections, and
structured generation around a target schema, then validate
the result before downstream use. Keep source data and its stricter output contract distinct.
Coordinate agents. A coordinator offers tasks to registered workers,
sends guidance, and reviews their results and evidence. The
task console shows the conversation and
provides the same offer and review operations.
Turn discovery into a repeatable workflow. Let an agent discover and
test gRPC services, then encode their calls and typed mappings
in a checked workflow. Run the stored definition directly
or submit it to durable jobs for asynchronous execution.
Use the pieces independently too. The library catalog covers
protobuf descriptors, validation, mappings, projections, schema management, and the
other building blocks behind these paths.
flowchart TB
schema["Shared protobuf contracts"] --> engine["ProtoMolt Java engine · coordination and workflows"]
agents["MCP · ACP · agent chat"] --> engine
engine --> agents
data["Kafka and connectors"] --> engine
engine --> data
engine --> services["gRPC services · different languages and runtimes"]
services --> engine
engine --> sinks["Sinks · storage and downstream systems"]
engine --> execution["Synchronous calls and asynchronous workflows"]
execution --> results["Typed results, recorded evidence, and receipts"]
The Java engine coordinates services and agents through protocol contracts. Participating services retain their own languages and runtimes.
Watch an agent work
One way to use the toolkit is to let an agent discover a running service and build a
repeatable integration. Step through this illustrative sequence of reflection, registry,
mapping, indexing, and code-generation operations.
agent
Reflectreflect
Registryregistry sync
Mapmap-message
Declarerender-index-mappings
SaveOpenSearch mapper
Generategenerate-stubs
The agent points at a running gRPC service it has never seen. One reflect call returns
the service's descriptors. No stubs, no generated code.
The six steps, as text
Reflect.The agent points at a running gRPC service it has never seen. One reflect call returns the service's descriptors. No stubs, no generated code.
Registry.The schema comes from the git-backed registry, where every registration is a single commit and a compatibility check stands at the write.
Map.A candidate mapping is tested on a sample document with the map-message verb. CEL expressions like title = body are exercised against real data before anything is saved.
Declare.Validation rules and a vector index hint are added to the schema itself, in the validate.v1 and index.hints.v1 dialects. render-index-mappings shows the index those hints describe.
Save.The mapped document is written downstream to OpenSearch, using an index mapping derived from the same hints. protomolt-search will honor the same hints again at search time.
Generate.generate-stubs runs protoc's own generators, compiled to WebAssembly, and emits a typed client. Nine targets are built in, and since the contract is standard protobuf, the client works in any of the 13 languages gRPC supports.
These capabilities are also available to applications and scripts. Hosts expose the
actions they mount through their supported surfaces; an indexing adapter can also be
called directly as a library. The surface guide explains which
calls are typed RPCs and which are contributed actions.
Try the service host
One Docker command boots the whole surface: a typed gRPC service with server reflection
on port 9090, and on port 8080 the REST gateway, the generated OpenAPI document, Swagger
UI, streamable-HTTP MCP, and the task console. The registry HTTP service rides along
inside the container. The demo seeds a sample demo.shop.v1.Order schema
(validation rules, indexing hints, metadata) and a sample workflow.
The repository's getting-started demo, with Docker installed
docker run -p 8080:8080 -p 9090:9090 pipestreamai/protomolt-serve --demo
Three ways to touch the same running instance, all against the demo schema:
README, Deployment: REST, validate a message against the schema's own rules
Descriptor-first libraries. Generic validation, mapping, and projection
code operates on protobuf descriptors and messages. It can serve a dynamic message
resolved at runtime or a generated application type. Domain services also use generated
messages for their own contracts.
Rules travel with the schema. Descriptor options can declare validation,
index hints, projection provenance, metric membership, and model instructions. Libraries
with readers for those options use them directly. Endpoints, credentials, and deployment
choices remain host configuration.
Shared actions across interfaces. A ProtoAction describes a callable
operation, its request and response, and its authorization scope. Hosts assemble catalogs
and expose them to their supported clients. Typed RPCs and contributed actions share this
integration model, while their availability depends on the selected host and modules.
Git is the registry. The schema registry's storage is a plain git
repository: every registration is one commit, history is git log, and review and
replication are whatever your git hosting already does. Federation between registries
is an ordinary git remote plus a strictly gated import.
ProtoMolt is early software under active development; its APIs may change.