Skip to content
Planned reference workflow

From an FMP request
to a maintainable pipeline.

The intended journey starts in your coding agent and leaves you with reviewable project files, running batch jobs, and evidence for maintenance. The complete production reference and FMP plugin are still being developed; the local validation plugin is available separately.

Available proof: The linked price example validates synthetic records locally. It does not establish FMP extraction, database publication, recurring operation, or production recovery.
An intended end-to-end journey

“Build batch pipelines for all symbols.”

That request starts a clarification process. “All symbols” needs a declared universe, dataset eligibility, and a feasible freshness plan for the user’s entitlements and API budget.

  1. Agree on the scope.

    The agent asks which datasets, symbol universe, history, destination, freshness target, API limits, and alert destination matter. Credentials are supplied through the chosen secret mechanism, not embedded in project files.

  2. Review a versioned project.

    The intended plugin guides the agent to supported pipeline configuration, data contracts, custom-code references, and runner configuration. Humans can inspect the same files. Proposed changes need review before deployment.

  3. Verify a bounded load and rerun.

    Check a small declared dataset against the actual destination, including rejected records, publication rules, and a safe repeat. A passing record fixture alone cannot prove these properties.

  4. Deploy recurring batch jobs.

    The first planned reference uses Prefect for scheduling and compute running PyCharter as a library. The project declares its deployment, secrets, durable state, and ownership. Closing the coding-agent session should leave the deployed jobs operational.

  5. Monitor coverage independently.

    Compare expected partitions and freshness with committed destination data. An independent monitor must detect missed work even when no job ran; a green process exit is insufficient evidence of complete ingestion.

  6. Review and verify maintenance.

    Use diagnostics, provenance, and progress to propose a repair. Review the configuration change, verify it, and perform a bounded rerun or backfill. Retries, checkpoint recovery, and lineage are advertised only after their runtime evidence passes.

FMP → YOUR DATABASEPLANNED REFERENCE WORKFLOW
01 / EXTRACTFMP data

Within your API budget

02 / VALIDATEPyCharter

Against versioned contracts

03 / LOADYour database

With publication rules

PLAN + REVIEW

You + coding agent plugin / recipe versioned project your deployment approval

RUN + MONITOR

Your scheduler + compute batch job using PyCharter your database

Your durable state and independent monitor support recovery and missed-run detection. The intended jobs continue after the agent exits; this reference deployment remains planned.

Make the important choices explicit.

Your agent clarifies the symbol universe, destination, API limits, and freshness needs before proposing a pipeline.

Explore the pipeline use case
01 / AGREED REQUIREMENTS
Source
FMP daily prices
Universe
Your chosen symbols
Destination
Your PostgreSQL database
Frequency
Based on freshness and API budget

Illustrative design, not a running FMP integration. Plugin packaging and the production reference workflow are in development. Recurring pipelines need a scheduler, compute, durable state, and monitoring.

Declare who operates each part.

In the default intended batch mode, you operate the scheduler, compute, destination database, durable state, and monitoring. PyCharter runs inside jobs that can exit between runs. An always-on PyCharter API, worker, or MCP server is not required by this mode; selected shared-service features may add their own requirements.

Agent guidance helps create and maintain the project. Authorization and database permissions belong to the declared runtime and infrastructure. The plugin alone cannot prevent alternate code or SQL from bypassing a check.

Review data and control responsibilities
Other illustrative patterns

Related work across the ecosystem.

These are architectures to explore, not preconfigured end-to-end deployments.

DATA ENGINEERING

Let agents build. Let contracts decide.

An agent can propose a transformation or pipeline. A generated implementation still needs an independent acceptance boundary.

  1. Human states intent and invariants
  2. Agent proposes an implementation
  3. Runtime contract checks the resulting data
  4. Host keeps the conformance report

Relevant packages: pycharter · pyintake

FINANCIAL WORKFLOWS

A decision can be good and still be unauthorized.

A model can propose an allocation, but trading requires separate risk, state, action, and accounting responsibilities.

  1. Research and optimization produce a proposal
  2. Trading risk policy evaluates limits
  3. Approval state controls progression
  4. Adapters execute; custody records fills

Relevant packages: pyoptima · pyfortis · pystator · pyactuator · pycustodian

ENTERPRISE OPERATIONS

Give tools a narrower path to action.

An agent working across documents, communications, and business systems needs context and scoped ways to act.

  1. Cited context supports a request
  2. Host assigns a tool profile and credentials
  3. Policy and state decide what proceeds
  4. External operation returns a receipt

Relevant packages: pyintake · pystator · pyactuator · pygubernator

Feedback