Skip to main content

​
What is oleander?

oleander is your agent’s data platform team. We host and manage storage and compute tools in a unified platform with automatic query routing, so your agent can query, transform, and run jobs without managing engines or infrastructure.

​
Who we are

oleander was founded by the co-creators of OpenLineage and Marquez. An open standard the data industry uses to emit and track lineage.

​
Agent in the loop

oleander is built around the idea that agents should be first-class participants in your data engineering workflow - not an afterthought bolted onto a dashboard. The six-step oleander agent loop Connect your agent via MCP and it immediately has access to your lake, catalogs, run history, lineage graph, costs, logs, and traces. Ask it anything:
“What’s the average petal length in the iris dataset, broken down by species?”
The agent calls oleander_list_catalogs to find your tables, then oleander_query_lake to run the query - no SQL written by you, no engine specified, no dashboard opened.
Agents don’t just query - they author jobs too. Give your agent a task and it will write the PySpark job, upload it as a versioned artifact, submit a run, and verify the output:
“Build a Spark ML classifier that reads oleander.default.iris, uses the sepal and petal measurements to predict flower species, trains and evaluates a random forest model, and writes the test-set predictions to oleander.default.iris_predictions.”
The agent calls oleander_upload_spark_artifact to store the script, then oleander_submit_spark_job to run it. Once the run completes, it verifies the output automatically - comparing row counts and byte volumes against the previous window, checking the schema diff, confirming lineage, and benchmarking cost per record. If anything regresses, it opens an investigation and surfaces a fix before you’ve noticed anything. Spark Streaming jobs follow the same pattern. The agent writes the streaming job, submits it to a connected cluster, and monitors run events as they arrive. If throughput drops or a batch fails, it surfaces the issue with full context so the engineer can act immediately.

​
Self-validating by default

Every run writes lineage, traces, and cost events to the lake automatically. oleander compares each run against the previous window, flags regressions in row counts, byte volumes, and duration, and surfaces anomalies before they reach production. Engineers and agents see the same signal. When the agent catches something, it opens an investigation with root cause, evidence from telemetry, and a suggested next step. No human has to notice the alert and open four tabs to figure out what happened.

​
Multi-engine, cost-aware

Agents routing through the MCP inherit this logic. A query that fits in DuckDB never hits Spark. A job that needs distributed compute gets submitted to the right cluster. Cost per record is tracked on every run.

​
How oleander works

1

Load your data

Upload files directly, sync from S3, or connect external catalogs like BigQuery or Snowflake. Your data lands in the oleander lake as Iceberg tables, queryable immediately.
2

Connect your agent

Add the MCP server in one command. Your agent gets access to 35 tools: lake queries, catalog management, lineage tracing, run inspection, cost attribution, and Spark job submission.
3

Run and validate automatically

Every job run emits lineage and telemetry. oleander validates each run against historical baselines, flags anomalies, and triggers investigations when something looks wrong.
4

Query from anywhere

CLI, API, MCP, tasks, and SDK all read from the same lake and context graph. Engineers and agents work with the same data, the same lineage, and the same cost signal.