<< goback()

fenic + Hugging Face Datasets: One-Line Agent Context Hydration

Kostas Pardalis

Kostas Pardalis

Co-Founder
fenic + Hugging Face Datasets: One-Line Agent Context Hydration

Fenic × 🤗 Datasets: One-Line Hydration for Agent Data Sandboxes

What e2b is for compute, Fenic is for data. With fenic you can snapshot your data, turn it into agent context, and expose MCP tools that safely bound what the agent can do. Today, we’re making that even easier: fenic now integrates with Hugging Face Datasets, so you can hydrate versioned context straight from the Hub, then safely tool it for your agents.

TL;DR

fenic now plugs directly into 🤗 Datasets.

Hydrate any tagged dataset into a fenic table with one line, then expose a bounded MCP tool surface over it. This makes context a first-class, versioned artifact: pin tags for deterministic runs, re-hydrate to roll forward/back without migrations, and share the exact setup across teams and environments.

Why this matters

In AI apps, product behavior isn’t defined by code alone, it’s also defined by context: prompts, MCP tooling, and the data you feed the model. That context must evolve with the same rigor as code: versioned, reviewed, evaluated, and deployed.

🤗 Datasets brings Git-style semantics, dataset cards, streaming, and scalable storage/compute patterns to ML data (structured and unstructured). fenic turns that data into a sandboxed agent context with a precise, safe tool surface (MCP). Together, they let you:

  • Clone code, hydrate data: pull an exact dataset version and materialize it locally.
  • Expose safe tools: give agents bounded powers (search/read/list/etc.) over that context.
  • Re-hydrate on updates: publish a new dataset tag → upgrade behavior by re-hydrating, no code changes.
  • Roll back: pin to any past tag for deterministic experiments and incident response.

Show me the magic

python
import fenic as fn

# HuggingFace connector - use hf:// scheme
df = session.read.csv("hf://datasets/squad/default/train.csv")

# or for parquet files:
df = session.read.parquet("hf://datasets/cais/mmlu/astronomy/*.parquet")
df = df.semantic.extract("context", schema=QuestionAnswer, model="gpt-5")

This one-liner turns a versioned dataset on the Hub into a local fenic table you can safely tool and serve to agents. Hydrate, serve, repeat.

fenic in one paragraph (context for the curious)

fenic is the data sandbox for agents: you snapshot your data, turn it into agent context, and expose MCP tools that bound what the agent can do. Think of it as data isolation plus a principled, auditable contract between agents and data. If e2b isolates compute, fenic isolates data.

Treating context like code

When you deploy code today, CI/CD builds, tests, and ships artifacts. With agents, you also deploy context. That means:

  • Version & review: propose context changes (new chunking, embeddings, filters, tool schemas) via PR.
  • Evaluate: run accuracy/latency/cost/PII checks in CI against a representative benchmark.
  • Publish: on green, push a dataset tag to the Hub.
  • Deploy: pin services to that tag; re-hydrate on rollout.
  • Revert: roll back by hydrating an earlier tag.

🤗 Datasets gives you the storage, streaming, and Git semantics. fenic gives you the runtime and tooling your agents use.

The “data sandbox” pattern

A fenic sandbox usually has:

  1. Code: a repo with your fenic transforms/schemas and an MCP server exposing specific tools.
  2. Data: a pointer to a 🤗 Dataset (or several) that represent the curated, versioned context.
  3. Hydration step: materialize the dataset(s) into local fenic tables when the service starts or updates.
  4. Tool contract: a minimal set of MCP tools (e.g., search, read_by_id, list_neighbors) that your agent is allowed to call.

Because the code and data are split, distribution is clean: anyone can clone the server, then hydrate the exact data version they need.

Example 1 — Documentation MCP server

  • Goal: let an agent answer product doc questions with citations.
  • How it works: build a doc index with fenic; publish it as typedef/fenic-docs-context@v0.2; consumers clone the MCP server code and run hydrate.
  • Update story: when you reindex the docs (say weekly), push v0.3; users re-hydrate to upgrade answers, no code changes, no migrations.

Why this is great: the tool surface stays stable; the dataset version changes. Your agent behavior improves predictably.

Example 2 — HN deep-research agent

  • Goal: synthesize Hacker News story threads with sources and citations.
  • How it works: publish an HN dataset on the Hub with precomputed embeddings and thread metadata; hydrate into fenic; expose search/read tools; let the agent plan and answer with bounded operations.
  • Repro: for experiments or benchmarks, pin to a dataset tag and record it in run metadata.

Bonus: you can offload inference into the sandbox, e.g., expose a fenic summarization tool so the deep-research agent stays lean and focused on reasoning instead of hauling a bloated context.

Under the hood

  • Hydrate from the Hub: Use the Hugging Face connector via the hf:// scheme. Pin to a Hub tag/commit when you need determinism.
  • Transform / annotate: Apply fenic ops locally, e.g., df.semantic.extract("context", schema=QuestionAnswer, model="gpt-5") and compose filters, joins, embeddings, etc., to shape the sandboxed context you want.
  • Local mutations are cheap: Treat the hydrated data as a scratchpad during a run. If it drifts, just drop it and re-hydrate cleanly from the Hub.
  • Re-hydrate on demand: Pull the same dataset (older/newer tag) to restore or upgrade the sandbox with zero migrations.
  • Serve tools via MCP (no handlers): In fenic, any query/transform can be declared as a tool like defining a view in a database. Register those tools and fenic serves them through its MCP server, giving agents a minimal, auditable surface (e.g., summarize, read_by_id, similar_neighbors).

Who should care?

If you’re building…

  • Context & memory engineering (ACE/GEPA): version “memory packs,” diff behaviors by tag, share across agents.
  • RL/agent gyms & evals: pin datasets for deterministic episodes; re-hydrate to compare runs cleanly.
  • Synthetic data pipelines: curate prompts/outputs as datasets; re-hydrate to retrain, ablate, or regress.
  • Repro benchmarks & leaderboards: publish corpora + harness so anyone can hydrate the exact setup.

In short: when your agents primarily work over data—think deep-research agents—you’ll want a versioned, hydratable data sandbox to keep them fast, safe, and reproducible.

Get started

  1. Install fenic, instructions on the repo here (don't forget to give it a ⭐!)
  2. Hydrate an example dataset and serve tools (see the snippet above).
  3. Check out the Docs MCP and HN Research Agent examples (links).

Shout-outs + Where to Find Us

We’re grateful to the Hugging Face team for the guidance and reviews, and to everyone who tested early builds.

We'd love to hear from you. Reach out to us on the HF Discord and join the fenic Discord to say hi! Share what you’re building, ask for help, or propose a feature. We’ll be there.

Share this post
the next generation of

data processingdata processingdata processing

Join us in igniting a new paradigm in data infrastructure. Enter your email to get early access and redefine how you build and scale data workflows with typedef.