You do not need another automation person who can wire up a few nodes and call it AI infrastructure. You need someone who understands where orchestration breaks when real agent state, auth, tool usage, webhook behavior, and production reliability all start colliding. That is the part I am strong in, and it is why I am a serious fit for Feros.
What makes this interesting is that the hard technical foundation is already there. The weak point in products like this is usually the layer between agent intent and business execution. That is where systems get messy, templates become one-offs, OAuth turns fragile, and evaluation stops being meaningful. I am good at stepping into that middle layer, structuring it properly, and making it usable by both the product and the engineering team.
-
I would start by reviewing where orchestration responsibility should live across the runtime, the graph layer, and n8n, because that decision will drive how clean or messy everything becomes afterward.
-
I would inspect how agent state is currently passed through prompts, tool calls, and external actions so n8n workflows receive enough structured context to make correct downstream decisions.
-
Before building templates, I would identify the highest value workflow patterns to standardize first, especially the ones most likely to expose weaknesses in auth, retries, data mapping, and state transitions.
-
I would define a repeatable contract for webhook and API interactions so you do not end up with a pile of custom logic that works once and becomes painful to maintain.
-
I would evaluate how OAuth and credential handling are currently modeled, because reusable workflow templates fail fast if credentials are not scoped, refreshed, and injected cleanly.
-
I would structure templates around real operational paths, not demo cases, so CRM updates, scheduling, support actions, and lead capture flows can actually be reused across agents.
-
I would review how tool calling currently behaves when external systems return slow responses, partial failures, invalid payloads, or conflicting records, because that is where production voice systems usually start showing cracks.
-
I would make sure evaluation loops measure whether a workflow produced the correct business outcome, not just whether a node ran without throwing an error.
-
I would look closely at how versioning should work between agent graphs and workflow assets so updates do not quietly break existing deployments.
-
I would help shape how n8n surfaces inside the product so it feels native to the agent system instead of looking like a separate bolt-on that users have to mentally translate.
-
I would keep the architecture pragmatic by pushing workflow logic into n8n where flexibility matters and keeping validation, adapters, and critical reliability paths in code where they belong.
-
I would also pressure test the integration layer for open source growth, because once outside contributors get involved, unclear conventions become a liability fast.
A few examples that are directly relevant:
Cococure AI WhatsApp Chatbot
This project is relevant because it involved building AI driven conversation flows that had to trigger the right business actions under real operational conditions, not sandbox logic. I served as Technical Consultant, Product Owner, and Project Manager, where I defined the orchestration structure, broke down the implementation into milestones, shaped how prompts interacted with external availability data, oversaw QA, and made sure the system behaved reliably once connected to live business workflows. The stack included OpenAI, LangChain, FAISS, Redis, FastAPI, WATI, and live API integrations. The part that ties most directly to Feros is that I was not just managing a chatbot. I was shaping the logic between AI behavior, external tools, system actions, and repeatable outcomes.
Select Screening Services Platform (https://stage.drugscreening-fe.testyourapp.online/)
This is relevant because it required building structured multi-role workflows where actions, statuses, external integrations, and audit trails all had to stay coherent across a live platform. I led the platform planning, technical direction, API structure, role based behavior, integration strategy, and delivery sequencing. That included handling where state changes should occur, how downstream actions should be triggered, and how to keep workflows understandable instead of letting them sprawl. The connection to Feros is direct: when you are building an orchestration layer for agents, clarity around system boundaries, execution order, and reliability matters more than clever demos.
YacDaddy.com SaaS Platform
This platform mattered because it replaced fragmented tools with a unified system that had to support subscriptions, role based actions, feature gating, operational workflows, and external integrations without becoming brittle. I led product and delivery planning, defined how moving parts should connect, and kept the implementation grounded in how the business actually operates. What ties this to your project is the need to turn complexity into a reusable system rather than a pile of special cases. That is exactly the challenge with building first class workflow support around AI agents.
I am open to a call if you want to get specific about how you want n8n represented inside Feros and where you see the current orchestration gaps.
-
Where do you want execution authority to sit when agent logic and workflow logic overlap or conflict?
-
Which use case do you see as the best first proving ground for template design: CRM, scheduling, support, or lead capture?
-
How mature is the current OAuth and credential model for tenant level or environment level reuse?
-
Are you treating n8n as an external orchestration engine, or do you want it exposed as a native part of the builder and graph system?
-
How are you currently measuring whether an agent workflow succeeded in a way that matters beyond technical completion?
Brandon
[email protected]