Home › Datasets › Agent Workflows & Multi-Step Planning

Agents & Tool Use Pack

How to Fine-Tune an LLM for Agent Workflows & Multi-Step Planning

Planning and executing multi-step agentic workflows — breaking a goal into ordered steps, tracking state, and adapting when a step fails.

Fine-tune a model on this dataset Preview Dataset

$35 for the dataset. Training is priced separately by model, starting at $47.

What can this kind of fine-tuning teach an LLM?

A general-purpose model may already know some of this subject. Fine-tuning serves a different purpose: it repeatedly demonstrates the kinds of requests, response patterns, terminology, decisions and workflows you want the model to handle more consistently.

For Agent Workflows & Multi-Step Planning, the dataset focuses on planning and executing multi-step agentic workflows — breaking a goal into ordered steps, tracking state, and adapting when a step fails. Fine-tuning shapes recurring model behavior; it does not turn the model into a live database or guarantee correctness on every new case.

What training data should cover

Useful supervised fine-tuning data should resemble the work you expect the model to perform. This Rebiha dataset's domain definition is organized around 12 coverage areas:

How Rebiha prepared the training material

This page contains 601 instruction-response pairs from the existing Rebiha dataset. Its domain definition was designed around the coverage areas above so the training material spans multiple realistic tasks rather than one narrow prompt pattern.

Rebiha's broader dataset workflow uses structured quality review to help identify problems such as contradictions, unsupported claims, unsupported assumptions, calculation errors and other weak training examples. You can inspect real examples on this page before deciding whether the dataset fits your model and use case.

What is in this dataset

601 instruction-response pairs covering planning and executing multi-step agentic workflows — breaking a goal into ordered steps, tracking state, and adapting when a step fails. Each pair is a realistic instruction with a full written response, in the JSONL format used for supervised fine-tuning. No synthetic filler, no duplicated rows.

Example pairs

Real rows from the dataset, shown in full.

I need to migrate our PostgreSQL database from an on-prem server to AWS RDS. The database is about 500GB with several large tables and some stored procedures. Plan the entire migration workflow, including the order of steps and what you would do if the initial data sync fails halfway through.

1. Pre-migration audit: inventory tables, indexes, stored procedures, triggers, roles, and extensions. Capture current schema with pg_dump --schema-only. 2. Provision RDS instance with same major version, enabling Multi-AZ and automated backups. 3. Create a migration user with replication privileges. 4. Set up AWS DMS (Database Migration Service) with a full-load-and-continuous-replication task from source to target. 5. Run schema deployment on RDS using the schema dump. 6. Start DMS full load; monitor task logs. If the full load fails (e.g., due to a table with unsupported data types or network drop), do NOT restart from scratch: instead, pause the task, capture the failing table name from DMS error logs, handle that table separately (e.g., using pg_dump for that table and pg_restore on RDS), then resume DMS with 'resume from checkpoint' if possible, or remove the problematic table from the task and continue with remaining tables. 7. After initial load, validate row counts and checksums on a sample of tables. 8. Cutover: stop writes to source, let DMS catch up to zero lag, then switch application connection string to RDS endpoint. 9. Post-migration: run integrity checks, re-grant roles, recompile stored procedures, and monitor performance for 48 hours before decommissioning source.

I'm building an automated report generator that pulls sales data from three APIs (Shopify, Salesforce, and Google Analytics), merges them, and emails a PDF every Monday. The Google Analytics API sometimes returns partial data or times out. Design a workflow that handles those failures gracefully without skipping the whole report.

Your workflow should be stepwise with per-source isolation and a fallback strategy. Step 1: Orchestrator triggers Monday 6 AM. Step 2: Fetch Shopify orders (last 7 days) — if fails, retry 3 times with exponential backoff (2s, 8s, 30s). If still failing, mark Shopify data as 'unavailable' and proceed. Step 3: Fetch Salesforce opportunities similarly, but if fails after retries, use cached data from last successful run + add a 'stale' flag. Step 4: For Google Analytics, implement a two-tier approach: first request the summary metrics (sessions, conversion rate). If that times out, fall back to a smaller date range (split into two 3-day queries) and merge. If partial data is returned (e.g., only 3 of 5 dimensions present), still accept it but log a warning and annotate the PDF footer with 'GA data incomplete — range adjusted'. Step 5: Merge all three datasets into a pandas DataFrame; if one source is missing, still generate the report but include a prominent 'Data availability' section listing which sources succeeded. Step 6: Render the PDF from a template. Step 7: Send email. If any source failed, include an attachment 'data_quality_report.csv' detailing what failed and what was used. Step 8: If the entire pipeline throws an uncaught exception, send a non-PDF alert email with the stack trace to the admin, and schedule an automatic retry for 1 hour later. Never block the email on a single API source.

My goal is to 'improve our customer onboarding experience' but that's too vague. Break it down into a concrete, ordered task list that an autonomous agent can execute, including specific deliverables and success criteria for each step.

Decompose into 7 concrete tasks, each with an exit criterion. Task 1: Define the current onboarding funnel — extract user event logs from the product analytics tool (Mixpanel) for the last 90 days, and produce a funnel diagram with steps: signup → profile completion → first core action → first paid upgrade. Exit: you have exact conversion rates per step. Task 2: Identify drop-off points — run a cohort analysis and user session replays for users who churned at each step. Deliverable: a ranked list of top 3 friction points with evidence. Exit: each friction point has a measurable metric (e.g., '45% of users abandon profile completion because of 10-field form'). Task 3: Generate and prioritize improvement hypotheses — for each friction point, propose 2-3 fixes (e.g., reduce fields, add tooltip, automate data import). Prioritize by impact/effort using ICE scoring. Exit: a prioritized backlog of at least 6 items. Task 4: Implement the top-1 fix as an A/B test — change the signup form from 10 fields to 5, with progressive profiling later. Deploy behind a feature flag. Exit: test is live with 50/50 traffic split. Task 5: Run the test for 2 weeks and analyze results — compare conversion rate, time-to-first-core-action, and retention. Exit: statistical significance at p<0.05 or a clear decision to iterate. Task 6: Roll out the winning variant to 100% of users and document the change. Exit: feature flag fully on, documentation updated. Task 7: Set up a monthly automated monitoring report that tracks the funnel and alerts if conversion rate drops below a threshold. Exit: report is scheduled and alert threshold configured. Only after Task 7 is done can the overall goal be considered 'improved' — you will have measurable before/after numbers.

Who this is for

Builders who want their fine-tuned model to reliably perform this specific capability, as part of a broader assistant or agent.

Which models this works with

The dataset is plain JSONL, so it works with any instruction-tuned open model. On Rebiha you can train it directly on:

Training uses LoRA, or QLoRA on a 4-bit base for larger models. Your base model's weights are never modified — training produces a separate adapter.

How it works

  1. Pick this dataset and a base model.
  2. Rebiha runs the job on a managed GPU. You set up nothing.
  3. Download your model: a ready-to-run GGUF, plus developer assets (adapter, tokenizer, configs).

Fine-tuning or RAG?

Use RAG when the model needs facts that change — your prices, your documents, today's inventory. Use fine-tuning when you want consistent behavior and structure without prompting for it every time. This dataset teaches the shape of this capability, not facts to look up.

How managed fine-tuning works

  1. Inspect the dataset examples and choose a compatible base model.
  2. Rebiha runs the training job on managed GPU infrastructure using LoRA or QLoRA as appropriate.
  3. Download portable model assets for your own workflow, including the available ready-to-run and developer outputs for the selected training path.

Fine-tuning or RAG?

Use fine-tuning when the objective is recurring behavior: response structure, domain patterns, terminology, workflow, or how the model approaches a class of requests. Use RAG when answers depend on changing or proprietary facts that should be retrieved at request time. The two approaches can also work together.

Know what goes in. Own what comes out.

You can inspect real examples before training, choose the model you want to adapt, and keep portable model assets when training is complete.

Related datasets

Start fine-tuning