Turn inquiries into organized next steps.
Collect customer details from incoming messages, identify missing information and prepare a response in your existing system for your team to approve.
Less admin. More time for customers.
Automate the work that's costing your business time and sales.
Customer requests, quotes, follow-ups and system updates can consume your team's day. I build AI-powered workflows around the tools you already use, with checks and approvals where your business needs them.
to a quote ready for review.
The request comes in.
Customer details and job requirements are organized in your existing system.
A draft is prepared.
Your pricing rules guide the quote. Missing details are flagged for your team.
You approve before it goes out.
Review the price, scope and customer message. Approve it, make a change or hold it for a conversation.
We scope and test the workflow with your team before putting it to work.
Your existing toolsYour business rulesHuman approvalsMeasured results
What we automate
Start with the work
that keeps piling up.
These are examples we can scope and test together. We pick one repetitive task, define a useful finished result and check whether automating it is worth the investment.
Turn job details into quotes ready for review.
Prepare a draft using your pricing rules and customer information. Flag missing details and unusual requests before someone approves the quote.
Keep follow-ups and records moving.
Prepare follow-ups for open opportunities and update customer records in your business tools. Your team controls what gets sent and handles exceptions.
Built around the tools
you already use.
We first check how your systems connect, what information the workflow needs and which actions require approval. We agree on running costs and limits before launch, so the work fits your day and your budget.
An example workflow
From incoming inquiry
to the next follow-up.
One process, with clear handoffs. We use this example to start the conversation. Your tools, rules and approval points determine what we build.
Capture the inquiry.
Bring a new customer email or form submission into the workflow.
Organize the details.
Prepare the customer record and flag information your team still needs.
Prepare the quote.
Draft the scope and price using your agreed rules. Hold unusual requests for review.
Your team approves.
Review the draft in an agreed channel, such as email. Approve, request changes or stop it before sending.
Prepare the follow-up.
Use the opportunity's status and your schedule to draft the next message for approval.
Update the records.
Save approved actions in your existing system and flag anything that needs a human decision.
Every result is checked against your agreed rules before anything is sent or saved. Checks can miss things, so we test with real examples and keep human review where it matters.
Discuss your workflowWorking together
One task. A measured start.
I'm Vincent Serpico. I've been writing software for more than 30 years. We start with your day-to-day work and agree on what a useful result would look like.
01 /
Find one costly task.
Walk through how it works today, how often it happens and where time or opportunities get lost. We record the starting workload and review time before deciding whether AI is a good fit.
02 /
Test one workflow.
Agree on a paid pilot with one process, a defined scope and clear success measures. I build and test it with representative work. Your team reviews outputs through a simple, agreed approval process.
03 /
Measure before expanding.
Review a weekly report in plain English: work completed, errors caught, corrections needed and time spent. Compare it with the starting process, including review time, before deciding what to expand.
Built by me · Six applications
The engineering
around the AI.
Six implementations, with their control architecture exposed: model decisions, tool contracts, feedback loops, permission gates and saved state. Follow a request through the harness and inspect the code behind the controls.
Inspect the system, not just the output.
Open a project’s engineering view to see the application harness, AI decisions and feedback paths. Select a component for its implementation, or trace an illustrative request. The diagrams start collapsed so you can explore the software first.
- Human decision
- Agent / model role
- Harness code
- Tools / state
01 / Digital Human Studio
Give a character a direction.
Build a performance.
Linux desktop app · Research prototypeDirect a virtual human by chat or by hand. Combine walking, motion clips and prop interactions into a sequence, save it as a reusable skill, and record the performance. Generate new motion from text with a separately configured local model.
Explore the harness, agents & feedback loopsModel decisions, tools, checks and recovery
ENGINEERING VIEW / Digital Human StudioDirector’s tool agent + motion runtime
Open full-size Call / controlResult / error feedbackState / persistenceScroll sideways to inspect the diagram
The assistant chooses studio operations. A separate simulation worker executes motion and reports what happened.
CONTROL ARCHITECTURE
How the system stays in control
The director’s assistant selects named tools, receives command results and can inspect scene state before choosing again. The same command interface serves manual controls. The worker runs sequences and records completion, rejection and fall events.
Evidence to inspectProvider loop · command acknowledgements · sequence completion events · recorded development sessions
Engineering boundary: Studio actions run without per-call approval. An accepted command is not a finished performance. Cancellation releases waiting tools but does not guarantee a model request or simulation has stopped; scene Stop and End session are separate controls.
Read the components and code references
- Director’s request
- The user chooses a local or cloud provider and gives a direction. Scene state and library contents are available through tools; the assistant is prompted to inspect the studio first. assistantSend / assistantNew
- Reply or turn limit
- The compatible-provider adapter defaults to 12 model rounds; the Claude adapter configures 24 SDK turns. A final reply is not independent proof of a completed performance. run_turn
- Manual scene controls
- The user can operate the scene directly. Scene Stop, assistant cancellation and ending the session are distinct actions; there is no approval prompt before each assistant tool. sendCommand / assistantStop
- Conversation + tools
- The adapter supplies conversation history, studio instructions and tool definitions. The Claude adapter exposes only studio tools and disables its built-in file and shell tools. AgentSDKAssistant / TOOL_SPECS
- Director’s assistant
- One assistant chooses studio operations such as searching skills, inspecting state or running a sequence. Tool results and errors feed later decisions; motion tracking is a separate runtime. OpenAICompatibleAssistant.run_turn
- Named tool dispatch
- The dispatcher rejects unknown names and catches handler errors. Individual tools check prerequisites and arguments; session launchers use a GPU lock. The host does not apply a universal approval or schema-validation gate. call_tool / start_session
- Reusable skill files
- Tools inspect skill metadata and save composed sequences. The worker reads clips from a library mounted read-only; generation can add clips separately when its prerequisites are prepared. get_skill / save_sequence
- Results + scene state
- Command acknowledgements report acceptance or rejection. Waiting tools can check completion events and return final state; get_state provides a fresh scene observation. A timeout does not imply the action was undone. _send / _wait_event / get_state
- Recorded commands
- Tools append timestamped commands and match worker acknowledgements. Manual controls append to the same command file. The worker owns sequence timing and execution. _send
- Session evidence
- The worker records video, events, motion traces and a session summary. The desktop bridge logs assistant events separately. These records support inspection, not automatic resumption of an interrupted assistant turn. session evidence / launcher checks
- Simulation worker
- The Isaac worker composes motion, advances sequence steps and reports outcomes. It rejects out-of-bounds destinations and blocks direction after a fall until reset. Physical tracking and direct pose playback have different behavior. apply_command / sequence execution
Research prototype with a local NVIDIA GPU runtime. Physical tracking can fall; kinematic playback follows poses without simulating balance or contact. Walking does not plan around obstacles.
How Digital Human Studio is built
A Python and Qt desktop shell brings the live scene, skill library and director’s assistant together. The assistant can use LM Studio locally or a configured cloud provider. It selects from named studio tools; results and errors return to the conversation so it can decide what to do next.
Buttons and assistant tools use the same recorded command interface. A separate Isaac Sim worker composes motion references and runs the sequence, using physical tracking or direct kinematic playback. Command acknowledgements, completion events and scene state distinguish an accepted request from a finished action.
Saved sequences become library skills. Local Kimodo generation can add new clips after the live session ends. Session recordings, motion traces and assistant transcripts provide evidence to inspect. Prop handling uses timed attachment to a hand; it does not simulate finger grasping.
The original application code is MIT licensed. Models, motion data and character assets retain their own terms, and setup requires separately prepared dependencies and assets.
02 / Prompt Maker
Turn a scene brief into generated media.
Creative productionBuild an editable shot list, generate stills and video, and assemble the result. The application checks the plan and runs the production steps, with saved progress for review.
Explore the harness, agents & feedback loopsModel decisions, tools, checks and recovery
ENGINEERING VIEW / Prompt MakerTool agent + compiled production jobs
Open full-size Call / controlResult / error feedbackState / persistenceScroll sideways to inspect the diagram
The server transports model turns. The browser validates and executes tools.
CONTROL ARCHITECTURE
How the system stays in control
A conversational agent proposes tools and scene plans. The harness validates the plan, compiles the production steps and runs the work. Results and validation errors return to the agent; job state lives separately from chat context.
Evidence to inspectScripted-model UI tests · shot-list validation · recovery tests · live-model eval harnessRead the tests ↗
Engineering boundary: Shot-list review is configurable. Saved item progress does not guarantee exact-step recovery after an interruption.
Read the components and code references
- Brief + app state
- A request, current application state, plan and tool definitions are sent through the assistant endpoint. POST /api/assistant
- Reply or stop
- The conversation loop limits rounds, stops repeated identical successful calls and reduces older context. These controls bound behavior; they do not establish creative quality. askAssistant / foldChat
- Shot-list review
- With jobsAsk enabled, a shot list is saved as an editable draft. Disabling it queues work; the separate start_job tool can also queue immediately. shot_list / start_job
- Context management
- The browser retains tool results, shrinks older context and can summarize the conversation before the next model turn. The server prepares the provider request. foldChat / askAssistant
- Assistant / model
- One assistant chooses supported actions and fills scene-plan fields. The harness receives the proposal; it does not treat the model response as executable production code. askAssistant
- Dispatch + plan checks
- runTool dispatches recognized operations. For shot lists, checkShots checks prompts, model capabilities, references and audio requirements; compileShots creates the lower-level execution sequence. checkShots / compileShots
- Saved job state
- Jobs save at item boundaries and on a heartbeat. Stale interrupted items are marked skipped for inspection; three consecutive instances of the same item error pause a job. loadJobs / runJobs / runJob
- Tool observations
- Results feed the next assistant decision. A tool error also prevents remaining tool calls in that same response from continuing blindly. askAssistant / runTool
- Compiled job runner
- The runner executes the scene plan compiled by application code. It invokes media tools, tracks units and can use an optional visual selection call. runJobs / runJob
- Persisted jobs
- The application persists job records separately from the transient model conversation. Recovery can require inspecting an interrupted item. saveJob / loadJobs
- Visual selection role
- A separate model call can compare renders and choose an image to carry forward. This is a specialized model role, not an independent coordinating subagent. brainPicks
- Media systems
- Media operations produce actual artifacts. A completed job can include skipped items, and image selection remains model judgment. compileShots
Shot-list review is on by default and can be disabled. Interrupted items may need inspection or a retry.
03 / Desktop Buddy
Carry a desktop task across files and tools.
Experimental desktop assistantDiscover tools, inspect the workspace and carry out permitted actions. The application controls execution and records progress so a person can inspect what happened.
Explore the harness, agents & feedback loopsModel decisions, tools, checks and recovery
ENGINEERING VIEW / Desktop BuddyGeneral-purpose tool agent
Open full-size Call / controlResult / error feedbackState / persistenceScroll sideways to inspect the diagram
Policy → execution → observation; the model proposes each next action.
CONTROL ARCHITECTURE
How the system stays in control
The model chooses tools. A host registry validates arguments, applies execution policy, records the pending call and returns observed results. The next decision sees that feedback.
Evidence to inspectPolicy tests · cancellation tests · checkpoint recovery · file readbackRead the tests ↗
Engineering boundary: A final model reply is not an independent completion check. Shell approval grants the command the user’s privileges.
Read the components and code references
- Task + execution mode
- The user supplies the task and execution mode. Planning rejects mutations; execution asks approval for designated risk categories. Policy.authorize
- Reply, stop or wait
- The default loop allows 100 rounds and stops repeated identical failures. A final reply can mark complete; that status does not independently verify the whole objective. Agent.run
- Human authorization
- Policy can require a human decision for commands, destructive actions, desktop input and other designated risks. Some workspace writes require no extra prompt. Policy.authorize
- Context assembly
- The harness loads task history and explicit memory, then compacts the request when needed. Stored history remains separate from the smaller model context. compact / Agent.run
- Agent / model
- One model-driven agent can discover a relevant subset of the registry and request a named operation. It receives results or errors before choosing again. discover_tools / run_tool
- Registry + policy
- The registry checks the tool name and schema, copies the arguments being authorized and applies host policy before invoking the handler. Registry.execute
- Task checkpoints
- The agent saves the pending call before execution, then records its result. Restart marks interrupted work; unresolved side effects are not automatically replayed. task state / checkpoints
- Observation + errors
- Tool results and errors are appended to the conversation. Particular tools verify particular effects; desktop actions often need a follow-up observation. Agent.run
- Tool execution
- Registered handlers execute allowed file, browser, system, desktop and media operations. File writes use atomic replacement and readback; cancellation cannot undo past effects. Registry.execute / Files.write
- SQLite state
- SQLite stores history, checkpoints, preferences and audit events. This supports inspection and recovery, rather than guaranteed exactly-once execution. Store
- External capabilities
- These tools reach beyond the model into real systems. The host selects the handler and enforces the execution policy; the model does not directly perform the write. Registry._register
Experimental. A task report is not independent proof of completion, and stopping cannot undo completed actions.
04 / AILC CRM
Turn a CRM request into a reviewed record change.
Business softwareFind the right record, collect missing details and prepare an update in plain language. A person sees the proposed change and confirms before the app applies it.
Explore the harness, agents & feedback loopsModel decisions, tools, checks and recovery
ENGINEERING VIEW / AILC CRMQuery agent + separately confirmed writes
Open full-size Call / controlResult / error feedbackState / persistenceScroll sideways to inspect the diagram
The chat loop proposes record changes; a separate server action performs confirmed writes.
CONTROL ARCHITECTURE
How the system stays in control
The assistant can query CRM data and prepare changes. Query results return to the model. A mutation proposal leaves the agent loop as a preview; a user confirmation invokes a separate authenticated write path.
Evidence to inspectQuery dispatch · structured pending actions · UI confirmation · mutation readback
Engineering boundary: Chat execution is request-scoped. UI confirmation is not a saved authorization token, and administrative writes need separate record-permission review.
Read the components and code references
- User request
- The user asks to inspect CRM data or prepare a record change. The API first requires an active authenticated session. Implementation:
POST /api/chat - Reply or loop limit
- The model can answer without another tool call. The request loop is bounded to five iterations, not a persistent background task. Implementation:
chat route loop - Session + context
- The route verifies the active session and uses recent messages to construct the model request. It does not establish a durable saved job plan. Implementation:
requireApiSession / messages - CRM assistant
- The model chooses CRM queries or requests structured pending insert, update and delete proposals. It receives query results in the current request. Implementation:
tool dispatcher - Tool dispatcher
- The dispatcher routes query calls to handlers. Mutation-oriented chat tools return pending action structures rather than applying those writes directly. Implementation:
executeToolCall / pending actions - Pending change preview
- The UI renders the proposed change. An update preview shows current and proposed field values; the preview itself is not an immutable server-bound authorization. Implementation:
UpdatePreview - Query observations
- Tool results are appended to the current request conversation so the model can disambiguate, query again or produce a pending proposal. Implementation:
tool_result messages - CRM query handlers
- Handlers query the supported CRM entities. The administrative client means authentication should not be confused with proven fine-grained record authorization. Implementation:
query handlers - Person confirms
- A click in the preview calls a separate server action. Cancelling does not apply the proposal. Implementation:
handleConfirmInsert / Update / Delete - Confirmed server action
- The server action checks the active session and allowed entity, strips bookkeeping fields from updates, writes the record and checks the result. Bulk inserts can partly succeed. Implementation:
chatBulkInsert / chatUpdateRecord - CRM database
- The records persist. That persistence is distinct from the bounded, request-scoped agent execution. Implementation:
Supabase operations
The assistant handles lookups and prepares the proposal. A person confirms record changes.
05 / Family Watchlist
Find a title and put it on the family list.
Shared household appSearch for a film or show, update a shared watchlist and adjust supported app features through a conversation. The assistant works through the app’s own household tools.
Explore the harness, agents & feedback loopsModel decisions, tools, checks and recovery
ENGINEERING VIEW / Family WatchlistApplication tool agent + usage accounting
Open full-size Call / controlResult / error feedbackState / persistenceScroll sideways to inspect the diagram
A bounded request loop; writes can execute directly through validated application handlers.
CONTROL ARCHITECTURE
How the system stays in control
The server builds household context and exposes supported app tools. The model chooses an operation, the handler checks its inputs and scope, and the result or error returns to the next model turn. Usage is settled separately.
Evidence to inspectRequest gates · household-scoped title operations · credit-accounting testsRead the tests ↗
Engineering boundary: There is no separate approval preview for every write. The eight-round limit bounds execution, not task success or exact in-flight spend.
Read the components and code references
- Household request
- The user requests a supported title or customization operation inside the shared application. POST /api/chat
- Stream reply / end
- The server streams text and tool events. The request ends when the model answers or the loop limit is reached; it is not a persistent agent job. MAX_LOOPS / SSE stream
- Access + context
- Before a model request, the route checks the session, entitlement, cached credits, rate limit and request structure. Context includes the household and supported app state. POST gates / systemPrompt
- Watchlist assistant
- A single assistant chooses library queries, title operations or supported customization tools. It cannot directly execute an arbitrary database command. streamed tool-call loop
- Tool argument handling
- The server assembles streamed tool calls, parses their arguments and dispatches known handlers. Invalid arguments and handler errors return as tool results. runTool
- Usage settlement
- The request records model usage, including an estimate where final usage is missing. A billing sweep retries reporting work; the upfront credit gate is not an exact ongoing cost cap. recordUsage / sweepAiBilling
- Tool observations
- The tool response is appended to model messages. Streaming activity also reaches the browser, while the model can choose another operation within the round limit. tool result messages
- Scoped app handlers
- Title creation and update validate expected fields. Applicable record lookups and mutations use the signed-in household. Writes and deletes can run without a separate preview approval. create / update / delete title
- Usage + billing state
- Usage and retry information persist separately from the request-scoped model loop. Reporting retries do not mean the user task itself resumes after a crash. usage ledger / meter events
- App records + search
- Handlers read and update the household library and can obtain title search/detail results. Application data persists beyond the request. title tools
Record tools can save or delete directly during a chat. There is no separate approval preview for every change.
How Family Watchlist is built
The server runs a request-scoped tool loop for title lookup, household records and supported customization. Tool errors return to the model so it can decide how to respond.
Records and usage persist; the conversation loop is not a resumable background job. Credits are checked before a request and usage is recorded afterward, rather than enforcing an exact in-flight spend ceiling.
06 / Newsletter Creator
Turn chosen sources into a newsletter draft.
Desktop appGather articles, draft an edition and revise the sections that need work. Export an editable Mailchimp draft for final review, with the source material close at hand.
Explore the AI workflow architectureModel roles, checks, revision and delivery
ENGINEERING VIEW / Newsletter CreatorEditor-directed model pipeline + export verification
Open full-size Call / controlResult / error feedbackState / persistenceScroll sideways to inspect the diagram
Models select and write within scheduled stages; no autonomous tool-selection agent loop.
CONTROL ARCHITECTURE
How the system stays in control
The application gathers sources, budgets model context and validates structured drafts. The editor requests revisions. Export tracks campaign/image IDs and reads Mailchimp content back to verify the saved draft.
Evidence to inspectKnown-source ID checks · no silent cloud fallback tests · export retry / readback testsRead the tests ↗
Engineering boundary: Source-ID validation does not establish factual accuracy. Active generation jobs are in memory; export checkpoints persist. Subscriber delivery is outside this app.
Read the components and code references
- Chosen source material
- The editor configures sources. Gathering extracts material, normalizes links and retains successful sources even when another source fails. gather
- Editor + issue profile
- The editor chooses which stage to run and reviews the issue. Those choices initiate handlers; a general autonomous agent does not decide the whole pipeline. handlers
- Fetch + normalize
- Application code fetches feeds/pages, extracts source text and records full-text or excerpt coverage. gather
- Selection role
- A model can select relevant links from a bounded list of HTML candidates. This stage does not grant arbitrary browsing or action authority. provider.complete
- Writing role
- The writer receives selected articles and the newsletter profile, then returns structured blocks. Prompts tell it to treat source material as content, not instructions. generateCopy
- Job control
- The job manager serializes inference and supports progress and cancellation. It is not a saved autonomous scheduler that resumes every interrupted generation. Jobs
- Editor review
- The editor can edit or request a rewrite and then export. Invalid output returns an error; it does not silently become a self-directed repair loop. generate / rewrite / export handlers
- Output validation
- Checks reject invalid block structures, unknown source identifiers and oversized single-block rewrites. Known identifiers do not prove a sentence is supported by the source. generateCopy post-checks
- Export checkpoints
- Saved issue and export records are separate from the active in-memory job. Campaign and uploaded-image identifiers are reused on retry. exportState
- Mailchimp adapter
- The adapter checkpoints destination identifiers, recovers uncertain campaign creation where possible, and reads saved content back to verify it. No send/schedule endpoint is used. exportMailchimp
- Mailchimp draft
- The finished integration result is a Mailchimp draft. A separate action outside this application sends or schedules delivery. Mailchimp export integration test
Export creates a Mailchimp draft. The application does not send or schedule subscriber delivery.
How Newsletter Creator is built
The application chooses the stages. Models select candidate stories and write structured newsletter blocks; they do not run a general autonomous tool loop.
Citation checks ensure identifiers refer to supplied sources, not that every sentence is factually correct. Export saves campaign and image IDs for retries and reads back the resulting content. Active generation jobs stay in memory.
What work would you like off your plate?
These projects demonstrate implementation patterns. We scope and test your business workflow separately, then measure the result.
VINCENT SERPICOPHOENIX, AZ
Who you'll work with
I lead the work, and I write the code.
I taught myself to code at 14. I started Founders Workshop, grew it into a 30-person development company and sold it in 2026. For 16 years we built software for small and mid-sized businesses.
I built the products on this page with AI assisting the development, and I review and test every change. I stay hands-on in every project, from understanding the work to checking the finished result.
Michael Herman
President
Michael has 30 years in solving digital problems for large brands, non-profits, startups, and small businesses, and has mentored startups since 2015.
Andrea Ramirez
VP of Operations
Andrea leads operations, process and coordination at Serpico AI. She brings more than 10 years of experience in operations and people management.
The team
Brought into a project when it needs their industry or specialty.
Daniel Love
Lynne Gabrielson
Ian Gatzke
Alexander Foster
Sabrina Valdez
David Rice
Lakshya Gupta
Kathleen Celmins
Alex Koupal
Practical questions
Before we talk.
Do I need to understand AI?
No. Bring one repetitive task and explain how your team handles it today. I'll work through the technical choices with you and explain what the workflow can do, where it needs review and what it will cost to run.
Will it work with our existing tools?
We check that before agreeing on a build. We look at how your email, spreadsheets and business systems can share information, what access is available and where your team will review the work.
What happens when it gets something wrong?
Checks flag missing information and results that break your rules. They cannot catch every mistake. During the pilot, your team reviews the outputs, we record corrections and we agree which actions must always wait for approval.
How do we know it's worth continuing?
We record the starting workload, errors and time spent, then compare the pilot with that baseline. Review and correction time count too. We agree on the measures before building and use the results to decide whether to continue.
What if our data has to stay private?
We'll review your contractual, security and data-handling requirements before choosing an approach. If your work requires processing on your own machines or offline, we can scope that separately, including hardware and support needs.
Who actually builds and supports it?
I lead the work and write the code. Michael and Andrea keep the company running, and the team contributes where a project needs their expertise. Before launch, we agree on support, ongoing costs and who handles exceptions.
Start with one task
What keeps taking your team away from customers?
Tell me about the repetitive work you'd like to reduce. A few sentences are enough. Your message comes straight to me, and we'll discuss whether it's worth automating.
Prefer LinkedIn? Message me there ↗