Tasky

Problem

Repetitive multi-step work — calling APIs in sequence, passing state between steps, handling failures — is usually glued together with one-off scripts that are hard to reuse, observe, or improve.

Why I built it

To provide a workspace-style control plane for orchestrating agents and workflows: define a task once as a modular workflow, then let agents plan, execute, remember, and improve on each run.

Architecture

1. 1

   Task definition

   Work is expressed as modular API-driven workflows — discrete steps with clear inputs and outputs that can be recombined.

2. 2

   Planning

   An orchestration layer turns a goal into an execution plan: which steps run, in what order, and with what tools.

3. 3

   Execution with tools

   Agents execute steps through LangChain/LangGraph tool calls against REST APIs, with Redis-backed state between steps.

4. 4

   Memory

   Run history and intermediate state persist in MongoDB and Redis so workflows can resume, be audited, and learn from prior runs.

5. 5

   Verification and replanning

   Step results are checked before the plan continues; on failure the system retries or replans instead of silently continuing with bad state.

Engineering challenges

• Designing workflow steps that are genuinely reusable across tasks instead of secretly coupled to one use case.
• Deciding what belongs in fast ephemeral state (Redis) versus durable history (MongoDB).
• Making agent failures visible and recoverable rather than silent.

Lessons learned

• Verification after every step is what separates an agent demo from a system you can trust with real work.
• Memory is a design decision, not a feature toggle: what the system remembers determines what it can improve.