Amfelt's First Version Is Ready for Closed Testing
Today we start running demos and tests of Amfelt’s first version with a small group of invited teams. This version covers the scope we set for a first release: getting data from a team’s own source systems into a documented data platform.
What the First Version Does
Amfelt’s agent runs inside your network. Once you install it and approve its registration, it connects to your source databases and files, reads their structure, profiles their contents, and records what it finds in an open data contract. If your organization turns on the AI advisor, it recommends how each table or file should be loaded. It applies the recommendations it is confident about, and your team can review any of them. Those it is unsure of wait for a person.
On a schedule, Amfelt extracts the data and loads it into your data platform, where it builds three layers: staging for the raw load, history for how your records change over time, and a bridge layer for analytics. Every run reports back what it loaded and how it went. If you turn it on, Amfelt also keeps Markdown documentation of your data contracts and configuration in your project’s Git repository, regenerated whenever the configuration changes.
What Comes Next
The next round of work is already under way. Incremental extraction will let a run read only the records that changed since the last one, instead of a full snapshot. You will also be able to pause, resume and rerun jobs.
This round adds two kinds of checks as well. Schema-drift detection will notice when a source’s structure no longer matches its data contract. Depending on how you configure it, it then stops the run, warns and continues, or adapts. Data-quality checks will validate loaded data against the schema and quality rules in the contract, and compare what a run landed with what it extracted, so lost records show up as a warning instead of a successful run.
External AI agents will get governed access to your catalog and data contracts, under the same access policies as the rest of the platform.
After that come REST API sources and more connectors, including popular databases and file formats. We sequence this work by demand rather than by calendar, so what the test teams need most will move up the list.
How the Tests Run
We work directly with each participating team. A test means installing the agent inside your network and running it against your own systems. The first version reads from PostgreSQL, DuckDB, CSV, Parquet and JSONL, and loads into PostgreSQL or DuckDB, so a good fit is a team whose data already sits there. The Platform Pages and the Documentation describe the first version in more detail.
If you would like a demo, or think your team would be a good fit for a test, Get in Touch .