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 record updates can eat your team's day. We set up AI to do the repetitive part inside the tools you already use. Your rules decide what it may do, and your team approves anything that matters before it goes out.
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.
No AI knowledge needed on your side. We start with your day-to-day work, agree on what a useful result looks like and measure against it. Three steps, each leaving you with something you keep.
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.
You keep: a written baseline and a straight answer on whether AI fits this task.
02 /
Test one workflow.
Agree on a paid pilot with one process, a defined scope and clear success measures. We build and test it with real examples from your work. Your team reviews the output through a simple, agreed approval step.
You keep: a working workflow and an approval routine your team already knows.
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.
You keep: the numbers to decide with, whether or not you continue.
Agent Showcase · Six applications
See it working
in real software.
Six applications we built. Each one hands the thinking to an AI and keeps the checking, the record-keeping and the final say with the software and the people around it. Open one to see how it works, step by step.
Every project follows the same pattern.
You ask. The AI drafts or decides. The software around it checks the work against fixed rules, and a person approves where it matters. The result lands in the tools you already use, with a record of what happened. Each project below shows that pattern in five steps.
- You
- The AI
- The app and your tools
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.
How it worksFive steps in plain terms, with engineering notes at the end
- You give a direction. Type it in the chat, or use the studio controls directly.
- The assistant plans the moves. It checks the scene and the motion library, then picks from a fixed list of studio actions.
- The studio checks each command. Unknown or incomplete commands are rejected. Every command is written to a log.
- The character performs. A separate simulation moves the character and reports back: accepted, finished or fell.
- Everything is recorded. Video, motion traces and the chat log are saved for review.
- Step 4 reports back to step 2 when needed.
Worth knowing: The assistant acts without asking first; you can stop the scene at any time. An accepted command is not a finished move, so the assistant checks the result before it reports back.
For engineers: components, boundaries and source references
Evidence to inspect: Provider loop · command acknowledgements · sequence completion events · recorded development sessions
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.
- 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.
How it worksFive steps in plain terms, with engineering notes at the end
- You describe the scene. A short brief: the subject, the mood, how many shots.
- The assistant drafts a shot list. It proposes each shot and which image or video model should make it.
- The app checks the plan. Missing prompts or unsupported options go back to the assistant to fix.
- You review and press Run. Edit the shot list first. Automatic runs can be switched on.
- The app generates the media. Stills, clips and the assembled film, with progress saved along the way.
- Step 3 fix and resubmit to step 2 when needed.
Worth knowing: Review before running is on by default and can be turned off. If a run is interrupted, the app marks the unfinished step for you to check rather than guessing where it left off.
For engineers: components, boundaries and source references
Evidence to inspect: Scripted-model UI tests · shot-list validation · recovery tests · live-model eval harness Read the tests ↗
Boundary: Shot-list review is configurable. Saved item progress does not guarantee exact-step recovery after an interruption.
- 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.
How it worksFive steps in plain terms, with engineering notes at the end
- You give it a task. And choose a mode: plan only, ask before risky steps, or run pre-approved steps.
- The assistant proposes a step. One action at a time: open a file, run a search, use the browser.
- The rules decide. Routine steps run. Risky ones wait for you. Some are blocked outright.
- You approve when asked. Commands, deletions and desktop input need your go-ahead.
- The step runs. The result goes back to the assistant, and every step is saved to a history.
- Step 5 result goes back to step 2 when needed.
Worth knowing: Experimental. Approving a command gives it the same permissions you have. When the assistant says it is finished, check the result; its word alone is not proof.
For engineers: components, boundaries and source references
Evidence to inspect: Policy tests · cancellation tests · checkpoint recovery · file readback Read the tests ↗
Boundary: A final model reply is not an independent completion check. Shell approval grants the command the user’s privileges.
- 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.
How it worksFive steps in plain terms, with engineering notes at the end
- You ask in plain words. “Update Dana’s phone number” or “Who hasn’t been contacted this month?”
- The assistant looks it up. It searches the CRM, read-only, and asks you if anything is unclear.
- It prepares the change. A preview shows the current and proposed values side by side.
- You confirm. Apply, or cancel. Nothing is written until you do.
- The record is updated. The app applies the change and reads it back to check.
Worth knowing: Only the confirmed change is written. Each chat request is limited to five rounds of searching, and a confirmation applies to that one preview, not to future changes.
For engineers: components, boundaries and source references
Evidence to inspect: Query dispatch · structured pending actions · UI confirmation · mutation readback
Boundary: Chat execution is request-scoped. UI confirmation is not a saved authorization token, and administrative writes need separate record-permission review.
- 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.
How it worksFive steps in plain terms, with engineering notes at the end
- You ask. “Add the new Pixar film” or “What did we save last week?”
- The assistant picks an action. Search, add, update or change a household setting, from a fixed list.
- The app checks it. Signed in? Right household? Valid details? Bad requests come back as errors.
- The list is updated. The result goes back to the assistant, which replies or takes the next step.
- Usage is counted. Each request is limited to eight rounds, and its usage is recorded.
- Step 4 result goes back to step 2 when needed.
Worth knowing: Changes to the list happen without a separate confirmation step. The round limit caps how much one request can do, not whether it was done well.
For engineers: components, boundaries and source references
Evidence to inspect: Request gates · household-scoped title operations · credit-accounting tests Read the tests ↗
Boundary: There is no separate approval preview for every write. The eight-round limit bounds execution, not task success or exact in-flight spend.
- 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.
How it worksFive steps in plain terms, with engineering notes at the end
- You choose the sources. Feeds and web pages, plus the audience and tone for this issue.
- The AI selects and drafts. It picks the relevant articles and writes the sections, citing its sources.
- The app checks the draft. Every citation must point to a real gathered source. Broken drafts are rejected.
- You edit. Change any section, or ask for a rewrite of one.
- Exported as a draft. A Mailchimp draft, read back to verify. Nothing goes to subscribers.
- Step 4 ask for a rewrite to step 2 when needed.
Worth knowing: Citation checks confirm a source exists, not that every sentence is accurate. Sending the newsletter happens in Mailchimp, outside this app.
For engineers: components, boundaries and source references
Evidence to inspect: Known-source ID checks · no silent cloud fallback tests · export retry / readback tests Read the tests ↗
Boundary: Source-ID validation does not establish factual accuracy. Active generation jobs are in memory; export checkpoints persist. Subscriber delivery is outside this app.
- 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 show how we build. Your workflow gets scoped and tested on its own terms, then measured.
Who you'll work with
A small team. The person who scopes your task also builds it.
You talk to the engineer, not a sales layer. Specialists join when a project needs their industry or skill.
Vincent Serpico
Founder · Lead engineer
Scopes, builds and tests every workflow himself. More than 30 years writing software, including 16 running a development company that built for small and mid-sized businesses.
Michael Herman
President
30 years solving digital problems for large brands, non-profits, startups and small businesses. Has mentored startups since 2015.
Andrea Ramirez
VP of Operations
Leads operations, process and coordination, with more than 10 years in operations and people management.
Specialists
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. We 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?
Vincent Serpico scopes and builds each workflow himself. Michael and Andrea run the company, and specialists join 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 us about the repetitive work you'd like to reduce. A few sentences are enough. Your message goes straight to the engineer who would build it, and we'll discuss whether it's worth automating.
Prefer LinkedIn? Message Vincent there ↗