How Fastyr turned an AI-agent vision into a coherent operating workspace
People needed to understand agents, tasks, files and connected tools that changed in the background. A polished product vision needed a consistent production interface and client-side data behaviour before users could reliably operate it.
Devntech’s scope: Devntech owned frontend engineering and client-side data behaviour within a cross-functional team. The AI platform, execution environment and integration catalogue are client-product context and are not attributed to Devntech.
Hero visual
An operating workspace for agents, tasks and progress
A command-center view using demonstration data and redacted workspace details.
The engagement
What Devntech built for Fastyr AI
Fastyr is positioned as an AI-native workspace for coordinating agents, tasks, files, knowledge and connected tools. Devntech translated completed designs into responsive product surfaces, a reusable component system and a shared client-side GraphQL data layer.
What we changed
- 1
Translated product designs into reusable responsive interfaces.
- 2
Built client-side GraphQL patterns for shared entities and actions.
- 3
Tested realistic loading, partial-data and error states before live endpoints were complete.
Qualitative evidence
What changed operationally
- Agent, workspace, task and integration state is represented consistently across product views.
- Reusable interface patterns cover loading, partial-data, error and optimistic-action states instead of only the ideal path.
- Documented GraphQL contracts allowed frontend work to proceed against realistic data states before every live endpoint was complete.
Evidence standard: These are delivered workflow and operating-state changes supported by the project record. They are qualitative results, not estimated percentages or modelled savings.
What Devntech continued to own
- Frontend engineering
- Design system
- Client data layer
This is what we mean by
AI implementationOperational flow
How the system works
The system is organized around three operational steps, with each handoff tied to a clear purpose and owner.
Workflow visual
From reusable component to live agent state
An annotated flow connecting Storybook states, GraphQL contracts and background progress updates.
Step 1
Build a reusable interface
Common patterns become responsive components with defined loading, error and success states.
Step 2
Agree the data contract
Frontend and backend work from queries, mutations and error behaviour that serve real product surfaces.
Step 3
Keep changing work consistent
Normalized client data and controlled live updates help the same agent or task appear consistently across views.
What changed in practice
Capabilities built around the real workflow
Specific system capabilities, described by the operational job they do.
Product state
Consistent task state across workspace surfaces
A product-state comparison showing the same agent or task in the command center and workspace.
- Component foundation
- A documented design system supports consistent product delivery.
- Shared client data
- Normalized GraphQL entities reduce contradictory agent and task states.
- Resilient real-time UX
- Loading, partial-data, error and background-update behaviour is designed into the interface.
Implementation detail
What made this system difficult - and how we handled it
The decisions below came from the operating constraints of this engagement, not from a generic technology template.
Autonomous work needs an interface for changing state
Fastyr’s product vision covered chat, files, work management, knowledge and a command center - not a single dashboard. Agents and tasks could change without a person clicking refresh, and the same entity could appear in several surfaces. If each screen held an independent copy, users could see conflicting status or progress for the same work.
The frontend therefore had to make background activity understandable while controlling the cost of staying current. The design problem was not simply displaying an AI response. It was giving people a dependable operating surface where they could observe work in progress, act on it and find the same truth across the workspace.
Reusable components made product states part of the design system
Devntech translated completed Figma designs into responsive React components documented in Storybook. Components were defined with loading, partial-data, error and success behavior instead of leaving those states to be patched separately in every feature. This made accessibility, responsive behavior and recovery patterns reusable product decisions.
Mocked GraphQL responses allowed those states to be built and tested before every backend endpoint was available. Frontend and backend engineers could agree queries, mutations, pagination and error contracts from actual interface needs, then work in parallel against realistic data rather than waiting for the complete live API.
One client-side source of truth kept work consistent
Apollo Client normalized agents, workspaces, tasks and integrations so the same entity could be reused across views. Optimistic updates made supported actions feel immediate while preserving rollback on failure. Subscriptions and tuned polling handled background changes without defaulting every screen to aggressive fixed-frequency requests.
Authentication was part of the same operating model: middleware attached and refreshed tokens, and logout cleared user-scoped cached data. Devntech’s scope stopped at the frontend and client data layer, but that boundary still carried product-level responsibility. The central lesson is that an AI product becomes operable when state consistency, failure behavior and session boundaries are designed as first-class features.
More like this
Internal software · Integration
Five to Nine
Workplace events platform
AI · Automation · Integration
Right-hand.ai
Security awareness training
Got a workflow like Fastyr AI’s?
Describe the process. We come back with what it costs today, what could be automated and what we would build first.
- For businesses with $5M to $30M in revenue
- No long-term commitment
- Start with one workflow
- Keep ownership of everything we build