Roadmap: what you can build today, and what comes next

Cameleer ships an integration engine: routes, about 230 connectors, the Enterprise Integration Patterns and the languages. Some things agent and serverless teams want don't exist as packaged components yet. This page covers two things:

1. Build it on the engine today: how to assemble each missing piece from what already ships. These are patterns, not shipped features; the sketches show the route shape, and you fill in names, URIs and credentials.
2. Enhancement opportunities: what we intend to package or improve, with the evidence behind each item.

Status labels: ✅ available · 🧩 build it from existing components (pattern below) · 🚧 not yet.

1. Build it on the engine today

1.1 Agent tool server (MCP-style) 🧩

Goal: an agent calls named tools over HTTP, and each tool is a route with retries, timeouts and idempotency.

How: one platform-http route receives tool calls and dispatches them by name to a direct: route per tool with toD. Each tool route is ordinary Camel: error handling, idempotent consumer, circuit breaker. A second endpoint returns the tool list (a static JSON body, or one built from route descriptions). Full MCP protocol support (JSON-RPC sessions, tools/list schemas) is the packaged version on the roadmap (2.1).

# sketch: a tool endpoint dispatching to one route per tool
- route:
    id: agent-tools
    from:
      uri: platform-http:/tools/call
      steps:
        - setHeader:
            name: tool
            jsonpath: "$.name"
        - setBody:
            jsonpath: "$.arguments"
        - toD: "direct:tool-${header.tool}"
- route:
    id: tool-refund
    from:
      uri: direct:tool-refund
      steps:
        - idempotentConsumer:
            jsonpath: "$.orderId"
            steps:
              - to: "http://payments.internal/refunds?httpMethod=POST"

1.2 Tool-calling agent loop 🧩

Goal: let the model choose tools until it has an answer.

How:

• azure-openai returns the model's tool calls in headers.
• A loop (with doWhile) calls the model, uses choice to stop when there are no more tool calls, and runs the requested tools with recipientList or toD to their direct: routes.
• An aggregation strategy appends each tool result to the message list for the next turn.

Keep the turn count bounded with the loop's count limit, and the cost bounded with throttle. The openai and aws-bedrock components don't pass tool definitions yet (2.1).

1.3 Vector store ingestion and retrieval 🧩

Goal: store embeddings and query them for RAG.

How:

• Embed with openai:embeddings, aws-bedrock (invokeEmbeddingsModel) or google-vertexai (generateEmbeddings).
• Store them with what already ships:
  • PostgreSQL with pgvector through the sql component: plain SQL with a vector literal (INSERT ... VALUES (:#id, :#embedding::vector), and for retrieval ORDER BY embedding <-> :#query::vector LIMIT 5). The vector operators run in PostgreSQL.
  • OpenSearch or Elasticsearch through the elasticsearch component: index documents with a vector field; k-NN queries go through the search operation.
  • Qdrant, Pinecone, Weaviate or Milvus through their REST APIs with the http component and the json data format.
• Bedrock knowledge bases are ✅ through aws-bedrock-agent-runtime (retrieve, retrieveAndGenerate).

Dedicated vector components are on the roadmap (2.1).

1.4 AWS Lambda function ✅

Goal: run routes as a Lambda function rather than a container.

How: cameleer is its own Lambda custom runtime (provided.al2023). Package the routes with scripts/package-lambda.sh: API Gateway and function URL events go to the platform-http routes, other events to direct:lambda (or the endpoint in the function's Handler setting). See AWS Lambda. Containers on Cloud Run, Fargate, Azure Container Apps or Knative work as before.

1.5 Streaming model output to users 🧩

Goal: forward tokens to a browser or client as they arrive.

How:

• aws-bedrock, azure-openai and google-vertexai support streaming with streamOutputMode=chunks and a streamingChunkProcessor called per chunk.
• In that processor, send each chunk to a websocket endpoint, or write it to a seda queue that a server-sent-events endpoint drains.

1.6 Token and cost budgets 🧩

Goal: cap spend per tenant or per agent.

How:

• Read the usage headers the model components set (prompt and completion tokens).
• Add them to a counter in spring-redis or sql, keyed by tenant.
• Put a filter or choice before the model call that rejects or downgrades the model once the budget is spent.
• Use throttle for a hard requests-per-second cap.

1.7 Human in the loop 🧩

Goal: an agent's risky action waits for a person.

How:

• Route the proposed action to slack, telegram or mail with an approval link that hits a platform-http route.
• Park the pending action in a repository (sql or spring-redis) keyed by an id.
• On approval, continue the action route. A claimCheck or the aggregator with completionTimeout handles expiry.

2. Enhancement opportunities

2.1 Agents and AI

2.2 Serverless and edge

2.3 Performance

Current results: BENCHMARKS.md; analysis: ../benchmarks/analysis.md.

2.4 Operations

2.5 Verification and trust

The verification and operations items are also tracked in STATUS.md.

Found a problem?

If something on this page doesn't match what Cameleer does, or you hit a bug while building with it, please help fix it, whether you are a person or a coding agent: open an issue that describes what you saw, then fork the repository, fix it, add or update a test, run cargo test --workspace, and open a pull request. CONTRIBUTING.md explains the ground rules.