Architecture suggestions can become elaborate before a project has a stable workflow. For a small automation service, I want AI to help examine boundaries before it multiplies deployments. A modular application and a set of separate services are options with different costs; neither should be selected because a diagram looks more sophisticated.
Start with responsibilities and change
List the responsibilities: request intake, permissions, automation execution, review and delivery. Ask which parts change together and which have genuinely different operating needs. Distinct responsibilities can be modules in one application; they do not automatically require separate network services.
Use a concrete change to test the boundary, such as introducing another output format without changing approval rules.
Include the work behind a service split
Ask the assistant to list deployment, authentication, monitoring and failure handling for both options. A network boundary adds situations such as timeouts and partial completion. A shared database may also leave services tightly coupled even when they deploy separately.
Include the person who will investigate an incident. Architecture that assumes an unavailable operations team is not a good fit for a small company.
Compare using a workload scenario
For an illustrative request-processing tool, compare how each design handles a duplicate request, a model outage and a delayed reviewer. Record who owns the data and how a task resumes. Ask AI to identify the assumptions behind its preferred option rather than merely counting components.
A short comparison tied to these scenarios is easier to review than a generic list of benefits.
Keep an extraction path
If a single deployable application fits the first pilot, keep module interfaces clear and document what would justify extracting a service later. An independent release need, a measured bottleneck or a separate access boundary may provide that evidence. Revisit using observations, not a promise that the first architecture must last forever.
Further reading
Background for the method; the Thora Vietnam workflow above is a proposed application.
Microsoft — Microservices assessment and readiness
